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FOREWORD 


THIS DOCUMENT CONTAINS THE CHARTS WHICH SUMMARIZE 
AND DESCRIBE THE RESULTS OF THE POWER MODULE DATA 
MANAGEMENT SYSTEM (DMS) STUDY PERFORMED BY IBM 
FOR THE GEORGE C. MARSHALL SPACE FLIGHT CENTER 
IN HUNTSVILLE, ALABAMA. THIS STUDY EFFORT WAS 
PERFORMED UNDER NASA/MSFC CONTRACT NO. NAS8-31747. 


INTRODUCTION 


This chart is self-explanatory 


INTRODUCTION 


o PURPOSE - Provide trades and analyses of selected Power Module Data Management Subsystem 
(DMS) issues to support concurrent inhouse MSFC Power Module Study 

o CONTRACT - MSFC Contract No. NAS8-31747 

o PERIOD OF PERFORMANCE - May 15, 1978 to December 1, 1978 

o SCOPE - Technical scope included the data management subsystem elements with emphasis on 

computer system trades and analyses and software requirements and definition 


o MSFC COR - Dr. J. B. White, Data Systems Lab, MSFC 


IBM POWER MODULE STUDY OVERVIEW 


This chart summarizes the major tasks and efforts performed during this study and a brief description 
of each task is as follows: 

o The Skylab hardware (ATMDC, WCIU and Support Equipment), flight, preflight, and support 
software were reviewed for potential use on the initial power module. 

o The Skylab flight and preflight software requirements and DMS processing functional 

requirements were used to provide the baseline software requirements for the power module. 

o The baseline computer speed and memory requirements were established and the requirements 
were personalized to the NSSC-I and NSSC-II computers. 

0 Alternate tradeable Data Management Configurations were defined, using NASA standard 
hardware, and tradeable items in the configurations were identified. 

o A trade was performed between the NSSC-I and NSSC-II computers and associated input/output 
equipment. 

o The DMS baseline interface requirements were defined. 

o An analysis was performed to define the Power Module DMS software development costs and 
to define a typical Software Development Facility configuration. 

o Potential DMS configurations using NASA non-standard hardware were evaluated. 

o An analysis was performed to define the functions in the centralized computer software 

which could potentially be allocated to subsystem microprocessors. 


IBM POWER MODULE STUDY OVERVIEW 


o REVIEWED POTENTIAL USE OF SKYLAB HARDWARE AND SOFTWARE FOR POWER MODULE APPLICATION, 
o PROVIDED DMS FUNCTIONAL PROCESSING, FLIGHT AND PREFLIGHT SOFTWARE REQUIREMENTS, 

o DERIVED COMPUTER SPEED AND MEMORY REQUIREMENTS FOR THE NSSC-I and NSSC-II COMPUTERS. 

i 

o DEFINED ALTERNATE TRADEABLE DMS CONFIGURATIONS USING NASA STANDARD HARDWARE, 
o PERFORMED TRADES BETWEEN THE NSSC-I AND NSSC-II COMPUTERS. 

o DEFINED A BASELINE DATA MANAGEMENT CONFIGURATION BASED ON COMPUTER TRADE RESULTS. 

0 DEFINED BASELINE DMS INTERFACE REQUIREMENTS. 

o PROVIDED AN ANALYSIS OF SOFTWARE DEVELOPMENT COSTS AND A SOFTWARE DEVELOPMENT FACILITY 

CONFIGURATION. 

o EVALUATED POTENTIAL ALTERNATE DMS CONFIGURATIONS FOR POWER MODULE APPLICATION. 

o ANALYZED CENTRALIZED COMPUTER PROCESSING FUNCTIONS FOR POTENTIAL DISTRIBUTION TO 
SUBSYSTEM MICROPROCESSORS. 


REPORT OUTLINE 


► o STUDY CONCLUSIONS AND RECOMMENDATIONS 

o SKYLAB HARDWARE AND SOFTWARE USAGE 

o COMPUTER MEMORY REQUIREMENTS 

o COMPUTER SPEED REQUIREMENTS 

o DMS CONFIGURATION TRADE OPTIONS 

0 DMS BASELINE CONFIGURATION DESCRIPTION 

o BASELINE SOFTWARE DEVELOPMENT FACILITY AND SOFTWARE COST SUMMARY 

o DMS OPTIONAL CONFIGURATION DESCRIPTION 

o MICROPROCESSOR PREPROCESSING OPTIONS 

APPENDIX A - POWER MODULE SUBSYSTEM PROCESSING REQUIREMENTS 


APPENDIX B - SKYLAB/POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS 


STUDY CONCLUSIONS AND RECOMMENDATIONS 


This chart summarizes the major study conclusions and the recommendations for further study 
effort. The primary study conclusions and recommendations are as follows: 

o An analysis of the Skylab residual hardware and software revealed that significant 

restoration of support hardware and software would be required and the use of newer 
technology DMS hardware for Power Module is recommended. 

o The trade study results recommended the NSSC-II be baselined for the Power Module 

DMS since the NSSC-II has high speed and memory margins required for potential growth 
options and has significantly lower software development costs for the Power Module 
application than the NSSC-I computer. 

o An evaluation of several potential data bus and remote I/O hardware vendors showed that 
several feasible candidates exist and more detailed trades and evaluations would be 
required to select the optimum configuration. 

o A subsystem microprocessor could be used for limited, repetition functions which could be 
reallocated from the main computer. However, system analyses were not performed to 
the point to enable a recommendation for such usage. 

o The DMS redundancy management concepts and requirements and the requirements and design of 
a computer "Redundancy Management Unit" require further study. 

o The detailed interface requirements between the DMS and other Power Module subsystems 
require further definition. 


STUDY CONCLUSIONS AND RECOMMENDATIONS 


o STUDY CONCLUSIONS 

USE UP-TO-DATE TECHNOLOGY DMS HARDWARE RATHER THAN SKYLAB HARDWARE 

USE NSSC-II AS BASELINE COMPUTER 

225% SPEED AND 250% MEMORY MARGINS 

- SIGNIFICANTLY LOWER SOFTWARE DEVELOPMENT COSTS FOR THIS APPLICATION THAN NSSC-I 

SEVERAL FEASIBLE CANDIDATES EXIST FOR DATA BUS AND REMOTE I/O HARDWARE 
o FAIRCHILD STAAC 

o SCI DACS 

o SPERRY FMDM 

A MICROPROCESSOR SHOULD PERFORM ONLY LIMITED, REPETITIVE FUNCTIONS IN SUPPORT OF THE 
FLIGHT SOFTWARE 

o DETAILED SYSTEM ANALYSIS WOULD BE REQUIRED TO DETERMINE THE AVAILABILITY 

OF MICROPROCESSOR TASK ASSIGNMENTS AND THEIR RELATED SYSTEM IMPACTS. 

o STUDY RECOMMENDATIONS 

o THE DMS REDUNDANCY MANAGEMENT AND THE COMPUTER "REDUNDANCY MANAGEMENT UNIT" REQUIRE 
FURTHER STUDY 

o MORE D ETA 1 1 ED TRADES ARE REQUIRED TO SELECT THE OPTIMUM DATA BUS AND REMOTE I/O HARDWARE 

o THE DETAILED DMS INTERFACE REQUIREMENTS REQUIRE FURTHER DEFINITION 


REPORT OUTLINE 


0 STUDY CONCLUSIONS AND RECOMMENDATIONS 
► 0 SKYLAB HARDWARE AND SOFTWARE USAGE 

0 COMPUTER MEMORY REQUIREMENTS 

0 COMPUTER SPEED REQUIREMENTS 

0 DMS CONFIGURATION TRADE OPTIONS 

0 DMS BASELINE CONFIGURATION DESCRIPTION 

0 BASELINE SOFTWARE DEVELOPMENT FACILITY AND SOFTWARE COST SUMMARY 

o DMS OPTIONAL CONFIGURATION DESCRIPTION 

0 MICROPROCESSOR PREPROCESSING OPTIONS 

APPENDIX A - POWER MODULE SUBSYSTEM PROCESSING REQUIREMENTS 


APPENDIX B - SKYLAB/POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS 


SKYLAB DMS HARDWARE AVAILABLE FOR POWER MODULE 


This chart summarizes the Skylab DMS hardware available to potentially support Power Module 
requirements and the minimum DMS hardware which would be required for Power Module. Seven 
Apollo Telescope Mount Digital Computer (ATMDC) and three Workshop Computer Interface Units 

CWCTUJ are available, but this is considered marginal in supporting one flight vehicle and 
associated ground equipment. All equipment spares have been sold and the test equipment is 

either scrapped or in unusable condition. 


SKYLAB DMS HARDWARE AVAILABLE FOR POWER MODULE 


• SKYLAB DMS HARDWARE AVAILABLE 
7 ATMDC'S IN STORAGE 
3 WCIU'S IN STORAGE 
2 WCIU'S SOLD TO PRIVATE CITIZEN 
NO MEMORY LOAD UNITS FOUND 
NO DMS SPARES - ALL HAVE BEEN SOLD OR SCRAPPED 
TEST AND VIBRATION TEST EQUIPMENT SCRAPPED 
ATMDC AND WCIU FIELD TEST EQUIPMENT IN UNUSABLE CONDITION 

e MINIMUM POWER MODULE DMS HARDWARE REQUIREMENTS 

1 SET (2 ATMDC, .1 WCIU) FOR FLIGHT (MORE REQUIRED FOR GROWTH) 

1 SET FOR ENGINEERING UNIT 
1 SET FOR FLIGHT SPARES 

POSSIBLY 1 SET FOR SOFTWARE DEVELOPMENT FACILITY 

UNKNOWN QUANTITIES OF SPARE PIECE PARTS AND SUBASSEMBLIES REQUIRED 

UNKNOWN QUANTITITES OF TEST EQUIPMENT REQUIRED 


SKYLAB SOFTWARE AVAILABLE FOR POWER MODULE 


This chart summarizes the availability of the Skylab software available to support Power Module 
requirements. In general, the hardware portion of the Software Development Facility has been 
disassembled and the various components either used for other applications or cannabilized. 

The basic software programs and definitions are available; however, some reconstruction and 
reorganization would be required to use the software with the Skylab ATMDC and WCIU. 



SKYLAB SOFTWARE AVAILABLE FOR POWER MODULE 


« SOFTWARE DEFINITION DOCUMENTS ARE AVAILABLE 

• FLIGHT TAPES AND COMPUTER LISTINGS WERE AVAILABLE PRIOR TO SKYLAB REACTIVATION WORK 

• SPECIAL SKYLAB SOFTWARE MODELING TOOLS ARE AVAILABLE 

• SOFTWARE DEVELOPMENT LAB HARDWARE IS SCATTERED 

S360/44 IS AT MSFC; TO BE SOLD OR USED ON OTHER PROGRAMS 
STATUS OF PERIPHERALS IS UNKNOWN 

ATMDC TO 360/44 HARDWARE ADAPTER HAS BEEN CANNIBALIZED 

• MISSION SUPPORT SOFTWARE IS AVAILABLE, BUT GENERALLY UNORGANIZED 


s 



SKYLAB DMS HARDWARE AND SOFTWARE USAGE SUMMARY 


This chart summarizes the conclusions and recommendations on the use of Skylab DMS hardware 
and software for the Power Module. 

The basic conclusion is that use of the existing DMS hardware and software would be a technical 
risk and costly endeavor, with only enough flight hardware to support one flight vehicle. 

Based on the conclusions shown, the recommendations are to use an up-to-date technology and 
design for the Power Module DMS rather than the Skylab ATMDC and WCIU. However, the Skylab 
concepts and functions should be used in a new Power Module Software Development Facility 
to develop flight software for the selected hardware. 


SKYLAB DMS HARDWARE AND SOFTWARE USAGE SUMMARY 


O CONCLUSIONS 

NOT ENOUGH SKYLAB DMS HARDWARE IS AVAILABLE TO SUPPORT POWER MODULE FLIGHT, SPARES 
AND GROWTH REQUIREMENTS 

THE DMS HARDWARE AND SUPPORT HARDWARE TECHNOLOGY IS OUTDATED AND EXTENSIVE COSTS RE- 
QUIRED TO MAINTAIN AND REPAIR. 

THE SKYLAB SOFTWARE DEVELOPMENT FACILITY IS NON-EXISTENT AND REDESIGN IS REQUIRED 

MOST FLIGHT AND SUPPORT SOFTWARE IS AVAILABLE, BUT EXTENSIVE REDESIGN AND RECONSTRUCTION 
WOULD BE REQUIRED 


o RECOMMENDATIONS 

USE UP-TO-DATE TECHNOLOGY DMS HARDWARE WITH READILY AVAILABLE FLIGHT AND SUPPORT 
EQUIPMENT AND SUPPORT SOFTWARE 

DESIGN A NEW SOFTWARE DEVELOPMENT FACILITY AND SOFTWARE, UTILIZE EXISTING SKYLAB 
SOFTWARE CONCEPTS AND FUNCTIONS AS APPLICABLE. 


17 


REPORT OUTLINE 


0 STUDY CONCLUSIONS AND RECOMMENDATIONS 

o SKYLAB HARDWARE AND SOFTWARE USAGE 

► o COMPUTER MEMORY REQUIREMENTS 

o COMPUTER SPEED REQUIREMENTS 

o DMS CONFIGURATION TRADE OPTIONS 

0 DMS BASELINE CONFIGURATION DESCRIPTION 

0 BASELINE SOFTWARE DEVELOPMENT FACILITY AND SOFTWARE COST SUMMARY 

0 DMS OPTIONAL CONFIGURATION DESCRIPTION 

0 MICROPROCESSOR PREPROCESSING OPTIONS 

APPENDIX A - POWER MODULE SUBSYSTEM PROCESSING REQUIREMENTS 

APPENDIX B - SKYLAB/POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS 

t? 

. h 

- fNTEMTJOPJALLY BLANK 
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POWER MODULE DMS FUNCTIONAL REQUIREMENTS 


The DMS processing functional requirements v/e re developed for each of the Pov/er Module subsystems. 
The chart gives a summary of the subsystem for which requirements v/ere developed. The charts 
detailing the requirements are included in appendix A. These functional requirements v/ere used 
as a basis for the speed and memory requirements defined in this study. 


POWER MODULE DMS FUNCTIONAL REQUIREMENTS 

• COMMAND PROCESSING 

• TELEMETRY PROCESSING 

• ATTITUDE CONTROL COMPUTATIONS 

• CREW DISPLAY AND CONTROL 

» ELECTRICAL POWER SUBSYSTEM SUPPORT 

• THERMAL CONTROL SUBSYSTEM SUPPORT 

• CRITICAL FUNCTION MANAGEMENT 


SELF TEST 


SKYLAB/POWER MODULE FLIGHT SOFTWARE REQUIREMENTS 


The Skylab ATMDC software requirements were converted to Power Module requirements and used as a 
basis for Power Module software sizing. 

The next three charts summarize the instructions, data, and speed requirements for the Skylab/Power 
Module software. The major functions of the Skylab/Power Module software are summarized and each 
routine or subroutine requirements are shown for each subfunction. 

The instructions are 16 bits, and the data is generally 16 bits. The sample rate is given in samples 
per second and the speed is given in instructions per second. The speed is shown for reference since 
it assumes that all instructions in the routine are exercised once at a maximum sample rate. Actual 
usage rates in the computer will vary. The source of the software requirement is shown at the 
right. The Skylab Program is the source for most software estimates. 

Approximately 13,220 instructions and 2,807 data words are required giving a total of 16,027 data words 
and instructions. 

The breakdown of the storage requirements shows approximately 10.8% for program control and utilities, 
20.7% for special purpose processing subroutines, 44.9% for application and control routines, and 
23.6% for onboard redundancy management. 

The flight software description pages included in appendix B give a brief description of each of the 
subroutines or functions sized in the Skylab/Power Module Flight software. The numbering of the 
subroutines on the presentation charts correspond to the subroutine descriptions included in appendix B. 
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SKYLAB/POWER MODULE FLIGHT SOFTWARE REQUIREMENTS (SHEET 1 OF 3) 


1.0 


2.0 


. 



SAMPLE 



INSTR 

DATA 

RATE 


FUNCTION 

(16 BITS) 

(16 BITS) 

(SAMPLES/SEC) 

SOURCE 

PROGRAM CONTROL SOFTWARE 

(807) 

(356) 


* 

1.1 EXECUTIVE 

641 

0 


SKYLAB 

1.1 EXECUTIVE DATA 

0 

254 


SKYLAB 

1.2 INTERMEDIATE LOOP PROCESSOR 

58 

16 

5/SEC 

SKYLAB 

1.3 SLOW LOOP PROCESSOR 

108 

86 

1/SEC 

SKYLAB 

GENERAL PURPOSE UTILITIES 

(575) 

( 0) 



ALERT UPDATE 

18 

0 


SKYLAB 

ARC - TANGENT 

70 

0 


- SKYLAB 

DOUBLE PRECISION MULTIPLY 

24 

0 


SKYLAB 

LIMITING SUBROUTINE 

16 

0 


SKYLAB 

MATRIX BY MATRIX MULTIPLY 

42 

0 

* 

SKYLAB 

MATRIX BY VECTOR MULTIPLY 

32 

0 


SKYLAB 

QUATERNION MULTIPLY 

70 

0 


SKYLAB 

SINE - COSINE ROUTINE 

48 

0 


SKYLAB 

SQUARE ROOT ROUTINE 

58 

0 


SKYLAB 

SET - RESET ROUTINE 

22 

0 


SKYLAB 

VECTOR CROSS PRODUCT 

34 

0 


SKYLAB 

VECTOR DOT PRODUCT 

32 

0 


SKYLAB 

SCALED DIVIDE ROUTINE 

109 

0 


SKYLAB 
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SKYLAB/POWER MODULE FLIGHT SOFTWARE REQUIREMENTS (SHEET 2 OF 3) 






SAMPLE 




INSTR 

DATA 

RATE 


FUNCTION 

(16 BITS) 

(16 BITS) 

(SAMPLES/SEC) 

SOURCE 

SPECIAL PURPOSE FUNCTIONS 

(1945) 

(1368) 



3.1 

INITIALIZE 

912 

30 

ONCE 

SKYLAB 

3.2 

DISCRETE INPUT PROCESSOR 

86 

26 

1/SEC 

SKYLAB 

3.3 

TELEMETRY PROCESSOR 

188 

184 

5/SEC 

SKYLAB 

3.4 

BCD DISPLAY 

434 

36 

1/SEC 

SKYLAB 

3.5 

INPUT READ 

118 

16 

5/SEC 

SKYLAB 

3.6 

OUTPUT WRITER 

87 

10 

35/SEC 

SKYLAB 

3.7 

RADIATOR DEPLOYMENT CONTROL 

120 

10 

1/SEC 

EST 

3.8 

DCS MEMORY LOAD BUFFER 

0 

158 


SKYLAB 

3.9 

COMMON DATA 

0 

416 


SKYLAB 

3.9 

DATA 

0 

482 


SKYLAB 

APPLICATION MODULES 

(6575) 

(612) 



4.1 

CMG CONTROL 

1810 

200 

5/SEC 

SKYLAB 

4.2 

CMG GIMAL ANGLE CALCULATION 

51 

4 

1/10SEC 

SKYLAB 

4.3 

GRAVITY GRADIENT DUMP 

876 

94 

5/SEC 

SKYLAB 

4.4 

NAVIGATION 

660 

68 

1/SEC 

SKYLAB 

4.4 

TIMING PROCESSOR 

195 

20 

1/SEC 

SKYLAB 

4.5 

ORBITAL PLANE ERROR 

64 

0 

5/SEC 

SKYLAB 

4.6 

STRAPDOWN REFERENCE 

878 

52 

5/SEC 

SKYLAB 

4.7 

COMMAND SYSTEM PROCESSOR 

1006 

126 

QN/CMND 

SKYLAB 

4.8 

MODE LOGIC PROCESSOR 

585 

28 

1/SEC 

SKYLAB 


- ATTITUDE HOLD PROCESSOR 

61 

5 

ON CMND 

SKYLAB 


- SOLAR INERTIAL PROCESSOR 

147 

5 

ON CMND 

SKYLAB 


- RANDOM REACQUISITION 

149 

10 

ON CMND 

SKYLAB 


- GG DUMP MANEUVER PROCESSOR 

93 

0 

ON CMND 

SKYLAB 


SKYLAB/POWER MODULE FLIGHT SOFTWARE REQUIREMENTS (SHEET 3 OF 3) 


SAMPLE 



INSTR 

DATA 

RATE 


FUNCTION 

(16 BITS) 

(16 BITS) 

(SAMPLES/SEC) 

SOURCE 

5.0 REDUNDANCY MANAGEMENT 

(3318) 

(471) 


SKYLAB 

CMG RM 

544 

40 

1/SEC 

SKYLAB 

RATE GYRO RM 

630 

78 

1/SEC 

SKYLAB 

RM CONTROL SOFTWARE 

561 

72 

1/SEC 

SKYLAB 

SUN SENSOR RM 

200 

6 

1/SEC 

SKYLAB 

SELF TEST PROCESSOR 

962 

220 

1/SEC 

SKYLAB 

SWITCHOVER PROCESSOR 

196 

0 

2/SEC 

EST 

SUBSYSTEM HEALTH CHECK 

225 

55 

1/SEC 

SKYLAB 

TOTALS 

13220 

2807 



TOTAL (INSTRUCTIONS + DATA) 


16027 



6.0 POTENTIAL GROWTH FUNCTIONS 





(NOT INCLUDED IN TOTALS) 





6.1 SOLAR ARRAY POINTING 

146 

30 

1/SEC 

EST 

6.2 THERMAL CONTROL 

180 

30 

1/SEC 

EST 

6.3 POWER DISTRIBUTION CONTROL 

175 

20 

1/SEC 

EST 


NSSC-I AND II MEMORY REQUIREMENTS 


The following chart is a comparison of memory and instruction requirements of the NSSC-I and 
NSSC-II computers. Typical mathematical; data conversion, manipulation and scheduling, and 
execution subroutines similar to those used in the Skylab software were selected and the specifi 
routines were coded for both the NSSC-I and NSSC-II computers. The chart shows the results by 
indicating the number of instructions required for each subroutine function and the approximate 
instruction ratio as well as the number and ratio of the number of bytes (8 bits) of storage. 

As shown, the NSSC-I requires more storage than the NSSC-II for comparable subroutines. 


NSSC-I AND NSSC-II MEMORY REQUIREMENTS 


MATHEMATICAL SUBROUTINES 

INSTR 

RATIO 

STORAGE 

(BYTES) 

RATIO 

NSSC-I 

84 

2 

168 

1.5 

NSSC-II 

48 

1 

112 

1 

DATA CONVERSION AND MANIPULATION 

NSSC-I 

26 

3 

75* 

2 

NSSC-II 

9 

1 

38 

1 

SCHEDULING AND EXECUTION FUNCTIONS 

NSSC-I 

40 

2 

90 

1 

NSSC-II 

20 

1 

80 

1 


* 


Includes 15-20 Bytes of constants not needed on the NSSC-II 


SAMPLE CODE - INDEXING SUBROUTINE 


This chart gives the sample code for a typical indexing routine for the ATMDC, NSSC-I, and NSSC-II Computers. 
As shown, the ATMDC and NSSC-II take 7 instructions each while the NSSC-I requires 13 instructions for 
the same subroutine. Other comparable subroutines were coded and used as the basis for the instruction 
and storage comparisons previously shown. 


SAMPLE CODE - INDEXING SUBROUTINE 


ATMDC 


NSSC-I 


NSSC-II 


LA 

’O'O) 

LDI 

TPTRV 

L 

4,0(9) 

MU 

'2' (2) 

MUL,1 

> 2 . 

M 

4,4(10) 

AD 

TMP1 

ADD 

TMPANS1 

ADR 

4,6 

STD 

TMP1 

ADE 

TMPANS1+1 

STD 

TMP1 

LA 

•2* CD 

ADC 

— 

L 

4,4(9) 

MU 

•4* (2) 

STA 

TMPANS1 

M 

4,8(10) 

STD 

TMP2 

LDA 

TPTRV 

LDR 

6,4 


ADD BITOl 
STA TPTRV 
LDI TPTRV 
MUL,1 '3' 

STA TMPANS2 
STE TMPANS2+1 


ATMDC - 7 INSTRUCTIONS 
NSSC-II - 7 INSTRUCTIONS 
NSSC-I - 13 INSTRUCTIONS 


SAMPLE CODE - DOUBLE PRECISION MULTIPLY 


This chart gives the sample code for a typical double precision multiply (32 bits X 32 bits) for the 
ATMDC, NSSC-I, and NSSC-II computers. As shown, the NSSC-II requires 3 instructions, the ATMDC 
requires 13 instructions, and the NSSC-I requires 20 instructions. 


SAMPLE CODE - DOUBLE PRECISION MULTIPLY 


ATMDC NSSC-I 


L 

A 

LDA 

A 

M 

C 

M 

C 

STD 

TMP 

STA 

TMP 

L 

B 

STE 

TMP11 

M 

C 

LOA 

B 

SR 

16 

M 

C 

AD 

TMP 

SRD 

17 

STD 

TMP 

ADD 

TMP 

L 

A 

ADE 

TMP+1 

M 

D 

ADC 

— 

SR 

16 

STA 

TMP 

AD 

TMP 

STE 

TMP+1 

STD 

TMP 

LDA 

A 



M 

D 



SDR 

17 



ADD 

TMP 



ADE 

TMP+1 



ADC 

-- . 



STA 

TMP 



STE 

TMP+1 

NSSC-I I 

- 3 INSTRUCTIONS 



ATMDC - 

13 INSTRUCTIONS 



NSSC-I 

- 20 INSTRUCTIONS 






J 

1 


NSSC-I I 

L A 

M C 

ST TMP 






NSSC-II FEATURES NOT AVAILABLE ON THE NSSC-I 


An analysis was performed to examine the reasons that the NSSC-I instruction requirements were higher 
than the NSSC-II for comparable subroutines. The individual characteristics of the NSSC-II that 
contributed to the differences are listed on the next chart. In general, the basic architecture 
and special instruction subsets of the NSSC-II are more powerful and extensive than the NSSC-I. 
Specifically, the availability of more registers to store data during intermediate operations and 
the higher capability instructions of the NSSC-II were the primary reasons for the difference. 


NSSC-II FEATURES NOT AVAILABLE ON THE NSSC-I 


o BASIC ARCHITECTURE 

16 GENERAL PURPOSE REGISTERS 

16, 32, AND 64 BIT REGISTER OPERATIONS 

MULTIPLE BASE REGISTERS 

BYTE ADDRESS CAPABILITY 

IMMEDIATE INSTRUCTIONS 

STORAGE TO STORAGE INSTRUCTIONS 

SUPPORTING INSTRUCTIONS FOR MULTIPLE ACCURACIES 

o SPECIAL INSTRUCTION SUBSETS 

BLOCK DATA OPERATIONS (MOVE, PACK, UNPACK) 

- BINARY/DECIMAL CONVERSIONS (CVB, CVD) 

CHARACTER TRANSLATIONS (TR, TRT) 

MULTIPLE LOAD/STORE REGISTERS (LM, STM) 
MULTI-FUNCTION BRANCHES (BXLE, BXH) 

INSTRUCTION EXECUTION CONTROL (EX) 
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MEMORY COMPARISONS - ATMDC, NSSC-I, NSSC-II 


Memory comparisons between the ATMDC, NSSC-I and NSSC-II were made by coding the same application on each 
computer. The software was divided into three categories; mathematical, data conversion, and scheduling. 

The ratios for memory conversion in bytes are given on the following chart. Also, the ATMDC is divided 

into five functional areas with an approximation of the type of coding in each area. The ratios were 

applied to convert to a memory size on the NSSC-I and NSSC-II. The NSSC-I and NSSC-II requirements 

are obtained by multiplying the ATMDC requirements by the appropriate scale factor and percentage 

utilization for each of the mathematical , data conversion and scheduling functions for each software category. 

Note that the ATMDC requires less memory than the other computers. This is due to its 8 and 16 bit instructions 

that can deal with 32 bit operands. 
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MEMORY COMPARISONS - ATMDC, NSSC-I, NSSC-II 


Scale Factor to Convert from ATMDC to: 


NSSC-I NSSC-II 


M - Mathematical 

2.5 

°0 

r~* 

D - Data Conversion 

1.5 

.5 

S - Scheduling 

1.0 

1.0 







ATMDC 

NSSC-I 

NSSC-II 



M 

D 

S 

(16 BITS) 

(16 BITS) 

(16 BITS) 

1 . 

Program Control 

10% 

20% 

70% 

807 

1,009 

790 

2. 

General Purpose Utility 

100% 

- 

- 

575 

1,438 

1,035 

3. 

Special Purpose Functions 

20% 

30% 

50% 

1,945 

2,820 

1,965 

4. 

Application Modules 

75% 

5% 

20% 

6,575 

14,136 

10,336 

5. 

Redundancy Management 

60% 

40% 

- 

3,318 

6,968 

4,247 




INSTRUCTION 

STORAGE 

13,220 

26,371 

18,373 




DATA STORAGE 

2,807 

2,807 

4,210 


TOTAL STORAGE (INSTRUCTIONS & DATA) 

16,027 

29,178 

22,583 


POWER MODULE COMPUTER STORAGE REQUIREMENTS SUMMARY 


This chart converts the Program Instructions and Data Requirements to actual storage requirements for 
both the NSSC-I and NSSC-II computers. For the NSSC-I, the instructions are 18 bits (16 bits) long and each 
instruction conforms to one 18 bit (16 bit) location in memory. Coded examples for the NSSC-II indicated 
an 80% - 32 bit instruction and a 20% - 16 bit instruction mix. Therefore, the conversion factor of 180% 
is used for determining the NSSC-II instruction storage requirements. The data words were assumed to be 
50% - 32 bit and 50% - 16 bit mixes and the conversion factor of 150% was used to determine the NSSC-II data 
storage requirement. 


POWER MODULE COMPUTER STORAGE REQUIREMENTS SUMMARY 


o FLIGHT PROGRAM STORAGE REQUIREMENTS 


NSSC-I 

26,371 

INSTRUCTIONS 


2,807 

DATA 

NSSC-I I - 

10,207 

INSTRUCTIONS 


2,807 

DATA 


0 NSSC-I REQUIREMENTS CONVERSION 

INSTRUCTION STORAGE = (26,371 INSTRUCTION) (1 WORD/ INSTRUCTION) = 26,371 WORDS (16 BITS) 

DATA STORAGE = ( 2,807 DATA) (1 WORD/DATA) + 2,807 WORDS (16 BITS) 

TOTAL STORAGE 29,178 WORDS (16 BITS) 

OR 

58,356 BYTES ( 8 BITS) 

o NSSC-I I REQUIREMENTS CONVERSION 

INSTRUCTION STORAGE = (10,207 INSTRUCTIONS) (180%) (1 WORD/INSTR) = 18,373 WORDS (16 BITS) 

DATASTORAGE = (2,807 DATA (150%) (1 WORD/DATA) = 4,210 WOR^S (16 BITS) 


TOTAL STORAGE 


22,583 WORDS (16 BITS) 
OR 

45,166 BYTES ( 8 BITS) 
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SKYLAB/ POWER MODULE PREFLIGHT SOFTWARE REQUIREMENTS 


To provide the Power Module preflight requirements, the Skylab requirements were converted to Power Module 
requirements. This chart gives an estimate of the preflight software requirements based on the type of preflight 
software functions required for the Skylab mission. As shown, approximately 11,450 instructions and data are 
required to support the preflight checkout functions. The functions to be performed by the preflight software 
are as follows: 

o Verify the internal operations of the flight computer and signal conditioning unit. 

o Verify the operation of the flight computer and its I/O interfaces. 

o Provide an aid in testing and evaluating the operation of the Power Module 

systems components during: 

Laboratory Simulation 
Post-Manufacturing Testing 
Thermal -Vacuum Testing 
Readiness test at the launch site 

The operational modes of the preflight software are as follows: 

o Continuous monitor mode - provide continuous monitor of the flight computer and its interfaces 
and output the interface data via telemetry 

o Commanded test mode - provide the capability to perform special tests and exercises of the 
flight computer and its interfaces. These commanded test routines shall be initiated and 
controlled via the command system. Wherever possible, commanded test routines shall be 
interrupted to allow execution of the monitor programs. 




SKYLAB/POWER MODULE PREFLIGHT SOFTWARE REQUIREMENTS 

MEMORY 



(16 BITS) 

SOURCE 

ATMDC PREFLIGHT EXECUTIVE 

800 

SKYLAB 

POWER UP AND INITIALIZE 

400 

SKYLAB 

COMPUTER SWITCHOVER CONTROL PROCESSOR 

50 

SKYLAB 

MAIN LOOP MONITOR 

MAIN LOOP MONITOR CONTROL 

125 

SKYLAB 

INTERFACE READ SUBROUTINE 

500 

SKYLAB 

SERIAL INPUT READ SUBROUTINE 

300 

EST 

ACQUISITION SUN SENSORS PROCESSOR 

200 

SKYLAB 

COMPUTER AND DMS TEMPERATURE PROCESSOR 

75 

SKYLAB/EST 

CMG PROCESSOR 

600 

SKYLAB 

DISCRETE INPUT PROCESSOR 

225 

SKYLAB 

DISCRETE OUTPUT PROCESSOR 

200 

SKYLAB 

RATE GYRO PROCESSOR 

225 

SKYLAB 

SINGLE MEMORY LOCATION PROCESSOR 

50 

SKYLAB 

ORBITAL INTERFACE PROCESSOR 

100 

EST 

COMMAND SYSTEM 

525 

SKYLAB 

COMMAND TEST ROUTINES 

SERIAL INPUTS READ TEST 

125 

EST 

COMPUTER MEMORY DUMP 

75 

SKYLAB 

COMPUTER MEMORY LOAD 

100 

SKYLAB 

ORBITAL INTERFACE TEST 

315 

EST 

CMG RATE TEST 

250 

SKYLAB 

CMG GIMBAL POSITION TEST 

375 

SKYLAB 

CMG CAGING TERMINATE 

50 

SKYLAB 

COMMAND TEST TERMINATE 

100 

SKYLAB 

COMPUTER SWITCHOVER AND RMU COMMON SECTION TEST 

400 

SKYLAB/EST 

DISCRETE OUTPUT TEST 

150 

SKYLAB 

SITE INTERFACE TEST 

1250 

SKYLAB 

INTERVAL TIMER TEST 

150 

EST 

MISSION ELAPSE TIMER TEST 

200 

SKYLAB/EST 

RATE GYRO TEST 

250 

SKYLAB 

RADIATOR DEPLOYMENT TEST 

110 

EST 

TELEMETRY SYSTEM INITIALIZE AND INTERFACE TEST 

350 

SKYLAB 

TELEMETRY PROCESSOR 

350 

SKYLAB 

ERROR PROCESSOR 

400 

SKYLAB/EST 

MISCELLANEOUS UTILITIES 

375 

SKYLAB 

SELF-TEST 

1200 

SKYLAB 

COMMON DATA 

500 

SKYLAB/EST 


TOTAL STORAGE 11,450 (INSTRUCTIONS AND DATA) 


39 


POWER MODULE PREFLIGHT STORAGE REQUIREMENTS - ATMDC, -NSSC-I, NSSC-II 


The conversion scalars developed on a previous chart were used to convert the estimated preflight Power 
Module storage requirements in the ATMDC to storage requirements in both the NSSC-I and NSSC-II. 

Since the preflight software storage requirements in all three computers are less than the flight software 
storage requirements, the required storage capability is determined by the flight software requirements. 


PREFLIGHT MEMORY COMPARISONS - ATMDC, NSSC-I, NSSC-II 


M - Mathematics 
D - Data Conversion 
S - Scheduling 


M D 


1. 

Program Control 

10% 

20% 

2. 

General Purpose Utilities 

100% 


3. 

Special Purpose Functions 

20% 

30% 

4. 

Application Modules 

75% 

5% 

5. 

Redundancy Management 

60% 

40% 


TOTAL 

INSTRUCTION 



DATA 

TOTAL MEMORY 


Scale Factor to Convert From ATMDC to: 
NSSC-I NSSC-II 



2.5 

1.8 



1.5 

.5 



1.0 

1.0 


S 

ATMDC 
(16 Bits) 

NSSC-I 
(16 Bits) 

NSSC-II 
(16 Bits) 

70% 

1140 

1425 

1117 


300 

750 

540 

O 

in 

3200 

4640 

3232 

20% 

3120 

6708 

4914 


1000 

2100 

1280 


8760 

15623 

11083 


2690 

2690 

4035 


11450 

18313 

15118 
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o STUDY CONCLUSIONS AND RECOMMENDATIONS 

0 SKYLAB HARDWARE AND SOFTWARE USAGE 

0 COMPUTER MEMORY REQUIREMENTS 

► o COMPUTER SPEED REQUIREMENTS 

o DMS CONFIGURATION TRADE OPTIONS 

0 DMS BASELINE CONFIGURATION DESCRIPTION 

0 BASELINE SOFTWARE DEVELOPMENT FACILITY AND SOFTWARE COST SUMMARY 

0 DMS OPTIONAL CONFIGURATION DESCRIPTION 

0 MICROPROCESSOR PREPROCESSING OPTIONS 

APPENDIX A - POWER MODULE SUBSYSTEM PROCESSING REQUIREMENTS 

APPENDIX B - SKYLAB/POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS 
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SKYLAB INSTRUCTION MIX ANALYSIS 


This chart shows the actual instruction mix for the Skylab computer and the instruction mix for a 
Gibson aerospace mix, which is a typical mix used to calculate computer speed. The Gibson aerospace 
mix was used as a basis for calculating speed capabilities and requirements for the ATMDC, NSSC-I, 
and NSSC-I I computers. 


SKYLAB INSTRUCTION MIX ANALYSIS 


GIBSON 



SKYLAB 

AEROSPACE 


(ACTUAL) 

MIX* 

ADDS 

74% 

74% 

BRANCHES 

19% 

20% 

MULTIPLIES 

6% 

5% 

DIVIDES 

1% 

1% 


*GIBS0N AEROSPACE MIX USED FOR POWER MODULE REQUIREMENTS ANALYSIS 


COMPUTER DUTY CYCLE ANALYSIS 


This chart compares Skylab and Power Module computer usage. It was developed by assuming that the 
Power Module usage requirements were similar to Skylab except for the experiment's subroutines which 
were deleted from the Power Module computer usage calculations. 

The duty cycles for the experiments were extracted from the various subroutines and added into the 
wait state component of time. Therefore, an average active cycle of 89.8" for the Skylab and 84.5% 
for the Power Module computer was derived. 


COMPUTER DUTY CYCLE ANALYSIS 



SKYLAB 

POWER MODULE 


ACTUAL 

ESTIMATE* 

WAIT STATE 


15.5% 

SLOW LOOP 

7 .0% 

5.9% 

INTERMEDIATE LOOP 

56.7% 

56.7% 

TELEMETRY 

5.3% 

1.1% 

SELF TEST/SWITCHOVER 

6.8% 

6.8% 

INPUT/OUTPUT 

14.0% 

14.0% 


100.0% 

100.0%. 


♦BASED ON POWER MODULE TYPE SOFTWARE EXECUTED IN SKYLAB COMPUTER (ATMDC) . 


COMPUTER SPEED REQUIREMENTS ANALYSIS 


This chart summarizes the calculations for deriving the average speed requirement for the Power 
Module computer. 

The speed capability of the ATMDC, NSSC-I, and NSSC-II computers was calculated using the Gibson 
instruction mix. The active state of the ATMDC and Power Module computer was calculated using the 
duty cycle analysis shown on a previous chart. The Power Module computer average speed was then 
calculated by using the active state (84.5%) times the max. speed (66.7 KOPS) of the Skylab computer. 
This gives a value of 56.4 KOPS for average speed which was used as the basis for further speed 
requirement calculations. 


COMPUTER SPEED REQUIREMENTS ANALYSIS 


0 COMPUTER CAPABILITIES USING GIBSON INSTRUCTION MIX 

ATMDC = 66.7 KOPS 
NSSC-I = 133 KOPS 
NSSC-II = 200 KOPS 

o COMPUTER ACTIVE STATE CALCULATION 

SKYLAB ACTUAL (ACTIVE STATE) - (WAIT STATE) = 100%-10.2% = 89.8% 

POWER MODULE PROJECTED (ACTIVE STATE) - (WAIT STATE) = 100%-15.5% = 84.5% 

0 SKYLAB SPEED REQUIREMENT USING GIBSON MIX 

AVERAGE SPEED = (AVERAGE ACTIVE DUTY CYCLE) X (MAX SPEED) = (89.8%) X (66.7 KOPS) = 59.9 KOPS 
o COMPARABLE POWER MODULE SPEED REQUIREMENT USING GIBSON MIX 

AVERAGE SPEED = (AVERAGE ACTIVE DUTY CYCLE) X (MAX SPEED) = (84.5%) X (66.7 KOPS) = 56.4 KOPS 


COMPUTER SPEED REQUIREMENT COMPARISONS ATMDC, NSSC-I, NSSC-II 


Computer speed comparisons between the ATMDC, NSSC-I and NSSC-II were made by coding the same application on 
each computer. The software was divided into three categories; mathematical, data conversion, and scheduling. 
The ratios for the conversion of instructions are given on the following chart. Also, the ATMDC is divided 
into five functional areas with an approximation of the type of coding in each area. The NSSC-I and NSSC-II 
requirements are obtained by multiplying the ATMDC requirements by the appropriate scale factor and percentage 
utilization for each of the mathematical data conversion and scheduling functions for each software category. 

These were the basic, average speed requirements. The adjustments for the specific computers are shown 
on the next charts. 
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COMPUTER SPEED REQUIREMENT COMPARISONS - ATMDC, NSSC-I, NSSC-II 


Scale Factors from ATMDC to; 
NSSC-I NSSC-II 




M - Mathematics 


1.8 

.9 




D - Data 

Conversion 

1.5 

.5 




S - Scheduling 


2.0 

1.0 







ATMDC 

NSSC-I 

NSSC-II 



M 

D 

S 

(OPS) 

(OPS) 

(OPS) 

1 . 

Program Control 

10% 

20% 

70% 

4,770 

8,968 

4,245 

2. 

General Purpose Utilities 

100% 

- 

- 

23,053 

41 ,495 

20,748 

3, 

Special Purpose Functions 

20% 

30% 

50% 

3,715 

. 6,724 

3,083 

4. 

App 1 i ca t i on Modu 1 es 

75% 

5% 

20% 

21 ,462 

39,168 

19,316 

5. 

Redundancy Management 

60% 

40% 

- 

3,400 

5,712 

2,516 


56,400 


INSTRUCTIONS/SEC 


102,067 


49,908 


NSSC-I and NSSC-II COMPUTER SPEED REQUIREMENTS ANALYSIS 


This chart adjusts the raw KOPS requirements of the two processors to compensate for features necessary for 
Power Module software development. 

The NSSC-I speed was modified to provide worst case speed requirements and the impact of no interval timer. 
Approximate code was generated to estimate the impacts for double precision routines. The impact of the 
reduced registers was estimated based on experience. 

For the NSSC-II two sample problems were coded and timed to estimate the memory and speed impact of 
floating point. (The time between fixed point and floating point add's is the significant difference). 

For both computers a worst case situation was developed by assuming the minor loop varied by no more than 
10% and that the major loop could vary by 100%. The minor loop value is small because the logic of a minor 
loop design tends to limit the amount of computation for the worst case. This is not true of the major 
loop, but the major loop variation is spread over all minor loop cycles. A 12% impact was added for each 
computer to account for this variation. 

The above impacts give a total requirement of 114.4 KOPS for the NSSC-I with an 85% duty cycle and a 
61.5 KOPS requirement for the NSSC-II with a 31% duty cycle. 


■ -T-r- „ '-, 

NSSC-I AND NSSC-II COMPUTER SPEED REQUIREMENTS ANALYSIS 


0 NSSC-I COMPUTER 

AVERAGE SPEED REQUIREMENT 

DELTA FOR VARIABLE PROGRAM FUNCTIONS (+12%) 

DELTA FOR NO INTERVAL TIMER 


102.1 KOPS 
+12.3 KOPS 
(SEE NOTE) 


TOTAL NSSC-I SPEED REQUIREMENT 
DUTY CYCLE 114.4/133 


114.4 KOPS 
85% 


o NSSC-II COMPUTER 

AVERAGE SPEED REQUIREMENT 

DELTA FOR VARIABLE PROGRAM FUNCTIONS (+12%) 

DELTA FOR FLOATING POINT 


49.9 KOPS 
+ 6.0 KOPS 
+ 5.6 KOPS 


TOTAL NSSC-II SPEED REQUIREMENTS 
DUTY CYCLE 61.5/200 


61 .5 KOPS 
31% 


NOTE: APPROXIMATELY 4 KOPS IMPACT IF INTERVAL TIMER NOT PROVIDED 


POWER MODULE COMPUTER SPEED REQUIREMENTS SUMMARY 


This chart summarizes the computer-speed capability, speed requirement and performance margin for the 
NSSC-I and NSSC-II computers. The capability of the machine is derived using a Gibson Aerospace Mix and 
the requirements are derived from the Skylab speed requirements modified by the individual capabilities 
of each computer. 

The NSCC-I has a margin of only 16% which is less than the 100% growth margin desired this early in the 
program. The NSSC-II, with 225% margin, has sufficient growth capabilities to accommodate program require- 
ment changes. 



POWER MODULE COMPUTER SPEED REQUIREMENTS SUMMARY 



CAPABILITY 

COMPUTER 

(KOPS) 

NSSC-I 

133 

NSSC-II 

200 


REQUIREMENT 

MARGIN 

(KOPS) 

(KOPS) 

114.4 

16% 

61.5 

225% 
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BASIC GUIDELINES FOR DMS TRADES 


After an initial analysis of the baseline requirements and potential tradeable configurations, basic 
guidelines and decisions were made to conduct the trades. These were: 

o The CD&H data bus system is the same to all potential configurations. 

o An Attitude Control System (ACS) Signal Conditioning Unit, having functions 

similar. to the Skylab WCIU, is required to interface between the C&DH RIU/EU 
and the ACS components and is the same for all potential configurations. 

o After an analysis of the data bus traffic, it was apparent that the data bus 
could handle the traffic required by the ACS and a separate, dedicated ACS 
computer was not required. 


Therefore, the basic DMS trade candidates were determined to be the NSSC-I and NSSC-II and their 
associated I/O components (STINT). It was also baselined that a computer redundancy management 
concept would be required with either configuration. 


BASIC GUIDELINES FOR DMS TRADES 
o C&DH IS SAME FOR BOTH CANDIDATE COMPUTER SYSTEMS 

o ACS/COMPUTER DATA FLOW REQUIREMENTS CAN BE HANDLED BY DATA BUS. THEREFORE, A 
SEPARATE ACS COMPUTER IS NOT REQUIRED 

o A COMPUTER REDUNDANCY MANAGEMENT CONCEPT IS REQUIRED WITH BOTH CANDIDATE 
COMPUTER SYSTEMS 

o BASIC TRADE CANDIDATES WERE THE NSSC-I AND NSSC-II AND ASSOCIATED I/O COMPONENTS 



DMS TRADE CONFIGURATION OPTIONS 


This chart summarizes the DMS configuration options considered for trades. Options II and IV were 
selected as the two most feasible options for detailed trades, and these were essentially trades 
between the NSSC-I and NSSC-II computers and associated stints. The other options were deleted 
from the detailed trades for the following reasons: 

o OPTION I - This option was deleted after the Skylab DMS hardware and software was deter- 
mined not to be a cost or technically effective solution to the problem. Newer technology 
equipment was baselined to replace the technology outdated Skylab DMS. 

o OPTION III - This option includes a dedicated computer for the ACS computations. The 
requirements analysis indicated that neither the data bus traffic requirements nor the 
speed and memory requirements dictated two high capability computers to operate the 
system, since one computer can easily handle all functions. 

o OPTION V - This option includes a dedicated loop between the NSSC- 1 I/STINT- 1 1 and the 
ACS/SCU. This option is a backup to the baseline system since it allows a direct closed 
interface between the computer and ACS, and essentially combines the characteristics of 
options III and IV. This option would be used if the data bus traffic or closed loop 
performance on the data bus were a problem. 


DMS TRADE CONFIGURATION OPTIONS 


CONFIGURATION 
OPTION I 


ATMDC/WCIU 

dedicated to ACS with a NSSC 
computer with STINT performing 
other onboard computation 
requirements. 

OPTION II 


NSSC- I, STAAC System 


OPTION III 


NSSC-I, STAAC system with 
NSSC-II as flight control computer 

OPTION IV 


NSSC-II, STAAC system 


OPTION V 

NSSC-II, STINT II with dedicated 
port to ACS signal conditioning 


RATIONALE FOR DELETION 


Not enough Skylab hardware available to support one 
flight vehicle and associated ground equipment. 


NSSC-I speed performance is marginally acceptable for 
the baseline Power Module requirements. It does not 
have 100% reserve KOPS capability, and therefore does 
not provide for the anticipated growth requirements. 


Sytem requirements do not justify use of both computers 
when the NSSC-II can meet all speed and storage requirements 


NSSC-II is heavier and consumes more power than NSSC-I, but 
provides more than 100% speed reserve capability and therefore 
option IV was considered to be more acceptable than option II. 


This configuration provides better closed loop performance 
between the NSSC-II and the attitude control system. This 
option was not selected only because the present system 
closed loop requirements can be met using the STAAC data bus 
system. If system requirements increase, then this would be 
a good solution to improving the closed loop performance. 
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OPTION I - ATMDC , WCIU AND NSSC-I OR NSSC-II WITH C&DH 


This configuration utilizes the ATMDC and WCIU to perform all measurements, calculations and issue 
commands to the attitude control system. The WCIU interfaces are designed to be compatible with 
the ACS equipment. Redundancy management for the attitude control system would be performed by 
the ATMDC software in conjunction with the hardware functions designed into the WCIU. 

The NSSC computer and STINT would be used for controlling other on-board systems and data handling 
functions as required. 

Insufficient quantities of the Skylab hardware and its associated test equipment were the main reason 
that this option was not acceptable. 


DIGITAL 
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OPTION II - NSSC-I COMPUTER WITH C&DH 


This configuration requires a signal conditioning unit (new design) to interface the attitude control 
system with the STAAC system. The NSSC-I/STINT I would be required to perform all measurements 
calculations and issue commands to the attitude control system via the signal conditioning unit. One 
of the serial command outputs from the RIU would be used to command the signal conditioning unit. A 
serial data input to the RIU would be used for transferring data from the signal conditioning unit 
to the RIU. A limited number of discretes would be utilized to develop the interface protocol between 
these two boxes. 

This option is identical to option IV with only the computer/STINT changed. Therefore, options II 
and IV become a trade between the NSSC-I and NSSC-I I. 
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OPTION III - DEDICATED NSSC-II COMPUTER FOR ACS FUNCTIONS 


This option utilizes the NSSC-II for attitude control measurements calculations and commands. The 
NSSC-II would take the major burden off the NSSC-I and provide growth margins for the power module 
systems. The signal conditioning unit will provide the NSSC-II with Interfaces to the STAAC system 
and the attitude control system. 

This configuration was not accepted because system requirements did not show the need for both 
computers. The capabilities of the NSSC-II exceed the system requirements sufficiently that no 
justification can be made for two computers. 



< MECHANICAL I 

















OPTION IV - NSSC-II COMPUTER WITH C&DH 


This configuration is identical to option II with a NSSC-II/STINT-II replacing the NSSC-I/STINT- I 
components. The advantages or disadvantages between option II and option IV can be determined 
from the trade charts on the two computers. Option IV has been favored only because of the higher 
speed and storage growth capability of the NSSC-II over the NSSC-I. The NSSC-II's instruction 
set gives the NSSC-II programming advantages. Certain other factors as can be seen on the trade 
charts favor th* NSSC-I. 




DATA MANAGEMENT SUBSYSTEM 























OPTION V - NSSC-II WITH DIRECT INTERFACE TO ACS 

This configuration uses the same physical hardware as option IV except that a direct interface 
port between the NSSC-II and the signal conditioning unit has been provided in the STINT II. 

This option would not be constrained to the data bus limitations of the other options since the 
NSSC-II would be in direct control of the signal conditioning unit and therefore the attitude 
control system. 

The current system data requirements are well within the capabilities of the data bus and there- 
fore option V is presently considered as an alternate to option IV and may be selected if data and 
command requirements show that the system becomes limited by option IV. 


DIGITAL 


OPTION V: NSSC-II 
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DMS COMPUTER TRADii DRIVERS 


This chart summarizes the major differences between the NSSC-I and NSSC-II computers. The preferred 
characteristic is indicated by the asterisk. 


The major advantages of the NSSC-I computer are the low power required for the computer/memory 
combination and the non-volatile sore memory which would not have to be reloaded after a power-down 
sequence. 

The major advantages of the NSSC-II computer are the performance and speed (speed and memory margins) capa- 
bilities, the more powerful instruction set, internal registers, and the availability of floating point and 
double precision arithmetic. The added features of the System/360 compatible support software, internal timers 
and code trace capability aid software design and reduce software development cost. 
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DMS COMPUTER TRADE DRIVERS 


CHARACTERISTIC 

POWER 

STORAGE 

OPERATIONAL SPEED 
SPEED MARGIN 
INSTRUCTION SET 
SOFTWARE DEV COST RATIO 
MEMORY MARGIN 
SUPPORT SOFTWARE 

♦PREFERRED CHARACTERISTIC 


NSSC-I 
♦LOW POWER 

♦NON VOLATILE CORE MEMORY 
APPROXIMATELY 133 KOPS 
16 % 

220 % 

100 % 

NO TRACE CAPABILITY 


NSSC-I I 

VOLATILE STORAGE 
♦APPROXIMATELY 200 KOPS 
*225% 

♦FLOATING POINT AND DOUBLE PRECISION 
* 100 % 

*250% (850%) 

*360 COMPATIBLE SUPPORT SOFTWARE 
♦VERSATILE I/O AND INTERRUPT FEATURES 
♦INTERVAL TIMER PLUS REAL-TIME CLOCK 

♦TRACE CAPABILITY WITH CLOCK RUNNING 
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COMPUTER CAPABILITY IMPACTS ON SOFTWARE DEVELOPMENT 


THIS CHART IS SELF-EXPLANATORY. 


COMPUTER CAPABILITY IMPACTS ON SOFTWARE DEVELOPMENT 


CAPABILITY 

NSSC-I 

NSSC-I I 

POTENTIAL IMPACTS 

FLOATING POINT 

NO 

YES 

INCREASE IN SOFTWARE DEVELOPMENT COST 
IF NO FLOATING POINT CAPABILITY 

DOUBLE PRECISION ARITHMETIC 

NO 

YES 

SPEED PENALTY IF NO CAPABILITY FOR 
DOUBLE PRECISION ARITHMETIC 

INTERVAL TIMER 

NO 

YES 

4 KOPS SPEED PENALTY AND POSSIBLE TIME 
ACCURACY IMPACT IF NO INTERVAL TIMER 
HARDWARE ADDITION TO ADD INTERVAL TIMER 
TO NSSC-I (STINT) 

TRACE CAPABILITY 

NO 

YES 

INCREASE IN SOFTWARE DEVELOPMENT COST 
IF TRACE CAPABILITY NOT AVAILABLE 

SYSTEM/360 COMPATIBLE SUPPORT 
SOFTWARE 

NO 

YES 

USE OF SYSTEM/360 COMPATIBLE SOFTWARE 
DECREASES TRAINING COST AND COST OF 
SIMULATION DURING SOFTWARE DEVELOPMENT 


COMPUTER SYSTEM COMPARISONS 


This chart shows the major items used in the computer system (computer, storage, and I/O) trade study and 
a summary of the assumed requirements or goals and the characteristics of each computer system to meet that 
requirement. In most cases, the assumed requirement is from the MSFC Pre-Phase A Study for the Power Module and 
is added to provide a yardstick in comparing the two computer systems with the ATMDC/WCIU system proposed in 
the MSFC Pre-Phase A study. The comparisons are made for two computers and two STINTS each, with a total 128K 
bytes (8 bits) of storage for the NSSC-I system and a total of 224K bytes (8 bits) of storage for the NSSC-II 
system. 

The comparisons were used as the basis for the computer system trade study shown on another chart. The cost 
comparisons were based on the assumed one-time cost for software development, the Software Development 
Facility and one set of DMS flight hardware with the NSSC-I system costs 30% more than tha NSSC-II 
system costs. The NSSC-II system is heavier and uses more power than the NSSC-I system: however, 
the NSSC-I computer does not meet the 100% speed contingency requirements. Some minor risk is assumed 
in the development of a STINT II to interface the NSSC-II with the central unit. 


COMPUTER SYSTEM COMPARISONS 



NSSC-I/STINT-I 

NSSC-I I/STINT II 

ASSUMED REQUIREMENT OR GOAL 

COST 

130% 

100% 

DMS FLIGHT UNIT PLUS SOFTWARE COSTS 

WEIGHT 

42.1 LBS. 

78.7 LBS. 

200 LBS. (MSFC BASELINE) 

POWER 

50.7 

237 

165 W (MSFC BASELINE) 

VOLUME 

1627 IN 3 

1936 IN 3 

8812 IN 3 (MSFC BASELINE) 

GROWTH MEMORY 

128K BYTES (8 BITS) 

1024K BYTES (8 BITS) 

TBD 

SPEED 

133 KOPS 

200 KOPS 

229 KOPS NSSC-I 
123 KOPS NSSC-I I 

PERFORMANCE 

MARGIN 

MINUS 41% 

PLUS 63% 

COMPUTER SPEED REQUIREMENT 
VS. CAPABILITY 

RISK 

NONE 

. STINT II DEV 

N/A 


77 


POWER MODULE DEVELOPMENT COST DELTAS 


This chart summarizes the cost deltas between the NSSC-I and NSSC-II computers. The scope of the 
elements included in the delta costs are one DMS flight hardware system, development of hardware 
for the DMS, test, and ground support equipment for the computers, the hardware for one engineering 
unit, one software development facility (SDF) and the flight and preflight software development. 

As shown, the identical cost deltas are negligible compared to the total cost of the hardware and 
software required to support the first Power Module. The system hardware delta costs favor the NSSC-I 
computer, but a software delta cost penalty of approximately 118% is required to program the NSSC-I 
computer, basically because of the more powerful instruction set of the NSSC-II computer and the 
lack of floating point and trace capability in the NSSC-I computer. Recurring hardware cost will 
also be greater for the NSSC-I because more memory is required to store the required program. 


POWER MODULE DEVELOPMENT COST DELTAS 


PARAMETER 

o COMPUTER FLIGHT HARDWARE (2) 

o STINT FLIGHT HARDWARE (2) 

o STINT DEVELOPMENT (NON-RECURRING) 

o COMPUTER GSE 

o ENGINEER UNIT (1) 

o SDF UNIT (1) 

o FLIGHT SOFTWARE 

o PREFLIGHT SOFTWARE 


COST DELTA 

NSSC-II NSSC-I 

+ 70K 

+ 34 K 
390K 

+ 46K 


+6.5K 

+6.5K 

+2.48M 

+419K 


+424K +3028K 


TOTAL DELTA COST = -2.6M FOR NSSC-II COMPUTER SYSTEM AND SOFTWARE 


COMPUTER SYSTEM TRADE SUMMARY 


This chart shows the result of the computer system trade study. The parameters traded are shown 
on the left with a relative weighting factor of from 1 to 10 given to each parameter. The cost 
and growth parameter were given the highest weighting for the study. Parameters used in the trade 
were summarized on the previous chart. A summary of the parameter evaluations is as follows: 

o Cost - The NSSC-I hardware and software systems costs were 30% higher than the NSSC-II systems 
cost; therefore, the NSSC-I received a low rating for cost. 

o Weight - The NSSC-II system is heavier than the NSSC-I system, but both are wet! within 
the MSFC Pre-Phase A study weight allocations. 

o Volume - The volumes for the two systems are comparable and within the MSFC study 
allocations. 

o Power - The NSSC-II system requires more power than the NSSC-I system and does not 

meet the study allocations, thus it was given the lowest rank. However, this will not 
be considered to be a major problem until Power Module power allocations are defined. 

o Growth - The speed and memory growth capability of the NSSC-I system is limited and the 
computer does not meet the basic plus 100% contingency basic requirement for speed. 

Therefore, the NSSC-I was given a low rank. 

o Performance - The NSSC-I does not meet the basic plus 100% contingency speed performance 
requirements and was given a zero rating. 

o Risk - No new development risk was seen for the NSSC-I system and only a minor risk for 
the STINT-II development. Therefore, the NSSC-II system was ranked slightly below the 
NSSC-I system. 

The results show that the NSSC-II/STINT-II is the preferred configuration, based on the cost, growth, 
and performance factors derived from the software requirements analysis. The NSSC-II provides a lower 
cost with higher speed and memory growth margins; therefore, a NSSC-II computer system is recommended. 


COMPUTER SYSTEM TRADE SUMMARY 


NSSC -1/ ST I NT I NSSC-II/STINT II 


PARAMETER 

WEIGHT 

RANK 

SCORE 

RANK 

SCORE 

REQUIREMENT OR GOAL 

COST 

10 

4 

40 

10 

100 

DMS UNIT PLUS SOFTWARE COSTS 

WEIGHT 

4 

10 

40 

8 

32 

R = 200 LB (MSFC BASELINE) 

VOLUME 

3 

10 

30 

■ 10 

30 

R = 8812 IN. 3 (MSFC BASELINE) 

POWER 

5 

10 

50 

o** 

0 

R = 165W (MSFC BASELINE) 

GROWTH 

9 

1 

9 

10 

90 

TBD 

PERFORMANCE (SPEED) 

7 

0* 

0 

10 

70 

R = 229 KOPS NSSC -I 
123 KOPS NSSC- I I 

RISK 

5 

10 

50 

9 

45 

NEW DEVELOPMENT 

TOTALS 



219 


367 



* DOES NOT MEET 100% CONTINGENCY REQUIREMENT 

** DOES NOT MEET POWER ALLOCATED IN MSFC BASELINE STUDY 


RECOMMENDATION: USE NSSC- I I COMPUTER SYSTEM FOR BASELINE 
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BASELINE POWER MODULE DMS BLOCK DIAGRAM 


This chart shows a block diagram of the baseline Power Module DMS design. The DMS is a dual 
redundant system with a single redundancy management unit and mass storage unit. The DMS consists 
of two NSCC-II computers, each with 11 2K bytes of storage, a single redundancy management and mass 
storage, two computer I/O units (STINT II), two central units, two data busses, 10 Remote Inter- 
face Units (RIU), and 16 Expander Units (EU), and two ACS Signal Conditioning Units. 

The STAAC Central Unit controls the data bus traffic by allotting data bus time slots to both the 
telemetry system and the computer. The computer's prime responsibility is Attitude Control and 
redundancy management of the Attitude Control System (ACS). The Signal Conditioning Unit (SCU) 
provides an interface between the ACS and the Data Bus RIU. The SCU performs AC and DC analog to 
digital conversions, digital to DC analog conversion, samples high level momentary and continuous 
discretes and outputs high level momentary and continuous discretes. 

Redundancy management of the computers is controlled by the Redundancy Management Unit (RMU). The 
RMU monitors a discrete from the active computer to ensure continued reliable performance of the 
computer. Mission critical data parameters are continually updated in the mass storage unit. 

When the RMU detects a computer failure, the active computer is powered off, the standby computer 
is powered on, and its memory loaded from the mass storage unit. The newly activated computer 
continues execution of the flight program. 























POWER MODULE BASELINE DMS EQUIPMENT REQUIREMENTS (PER VEHICLE) 


This chart summarizes the DMS equipment or components required for each flight article. As shown, 
the DMS is a dual -redundant configuration with a prime and redundant component except for the Redundancy 
Management Unit and Mass Storage which have the required redundancy and fail-safe mechanisms designed 
into the unit. 

The chart also summarizes the weight, power, and volume requirements of the components of the Power 
Module DMS. The weight and volume are given for the number of each component indicated while the 
power is given for the number of units assumed operating, which is typically a simplex configuration. 


POWER MODULE BASELINE DMS EQUIPMENT REQUIREMENTS (PER VEHICLE) 


COMPONENT 

NUMBER 

WEIGHT 

(LBS.) 

POWER 

(WATTS) 

VOLUME 
(CU. IN 

NSSC-II COMPUTER 

2 

75 

232 

1760 

STINT II 

2 

6 . 

3.5 

352 

REDUNDNACY MANAGEMENT UNIT 
+ MASS STORAGE 

1 

TBD 

TBD 

TBD 

CENTRAL UNIT (CU) 

2 

12 

14.4 

425.3 

BUS COUPLER UNIT 

4 

.6 

— 

12 

DATA BUS 

2 

TBD 

TBD 

TBD 

REMOTE INTERFACE UNIT (RIU) 

10 

43.5 

21.9 

1400 

EXPANDER UNITS (EU) 

16 

32 

3 

125.4 

ACS SIGNAL CONDITIONING UNIT 

2 

20 

15 

700 


COMPUTER REQUIREMENTS SUMMARY 


This chart summarizes the capability of the NSSC-II computer with 56K words (16 bits) of storage to 
support the Power Module computer requirements. As shown the NSSC-II gives over 100% margin for the 
speed and approximately 100% margin on the storage requirements in the baseline configuration. An 
expanded capability of the storage allows a maximum of 512K words (16. bits) if required. 

The reliability, weight, power and volume requirements for the Power Module computer have not been 
established. The NSSC-II capability is shown on the chart for a simplex computer with 56K words of 
storage. 
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COMPUTER REQUIREMENTS SUMMARY 


BASELINE 

REQUIREMENTS 


SPEED 

62 KOPS + 

100% CONTINGENCY 

STORAGE 

23 K WORDS 

+ 100% CONTINGENCY 

RELIABILITY 


TBD 

WEIGHT 


TBD 

POWER 


TBD 

VOLUME 


TBD 


S* ■ 


NSSC-II 

CAPABILITY 

200 KOPS 

56K WORDS (512K WORDS-EXPANDED) 
7,936 HRS. MTBF 
37.5 LBS 
232 WATTS 
880 CU. IN. 
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STINT II FUNCTIONAL BLOCK DIAGRAM 


This chart shows a functional block diagram of a proposed STINT II which would be used with the NSSC-II 
computer. The STINT II will provide the basic function for the NSSC-II computer that the STINT-I 
provides for the NSSC-I computer. 

The STINT II is proposed to provide the capability of interfacing the NSSC-II computer to the STAAC 
central unit, provide a MIA interface to the arbiter data bus system and an optional parallel inter- 
face to other subsystems such as the ACS Signal Conditioning Unit. The STINT II shall also provide 
interfaces between the NSSC-II and the communications system plus a RMU discrete to the Redundancy 
Management Unit. 


STINT II FUNCTIONAL BLOCK DIAGRAM 
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NSSC II 



PREMODULATION 
PROCESSOR - PR IME 

PREMODULATION 
PR OCESSOR - 
R EDUNDA N T 



OR BITER 
INTERFACE 



REDUNDANCY MANAGEMENT UNIT FUNCTIONAL BLOCK DIAGRAM 


This chart shows a functional block diagram for a proposed redundancy management unit and a 
mass storage unit for storage of the onboard software and critical onboard paramaters. 

The Redundancy Management Unit (RMU) is proposed to be a fault tolerant unit monitoring the RMU 
discretes to determine the condition of the active computer. If a computer failure occurs, the RMU 
will command power to be removed from the active computer and applied to the standby computer. The 
RMU shall then initiate a memory load to the newly active computer memory from the mass storage 
unit. Flight programs plus constantly updated critical flight parameters shall be stored in the 
mass storage unit. 


RMU DISCRETE (PRIME) 


RMU DISCRETE (REDUNDANT) 


NSSC II 
CONTROL 


NSSC II 



NSSC II NSSC II 

INTERFACE INTERFACE 
(PRIME) (REDUNDANCY) 













ACS SIGNAL CONDITIONING UNIT FUNCTIONAL BLOCK DIAGRAM 


This chart shows a functional block diagram of a proposed ACS Signal Conditioning Unit (SCU) which 
would be reguired to adapt the signals from the ACS CMG's, gyros and sun sensors to the RIU/EU's. 
The proposed ACS Signal Conditioning Unit (SCU) would accept commands from the computer via an RIU 
interface. The SCU would be capable of converting AC or DC Analogs to digital words, scaling 
high level discretes, storing momentary discretes and, on command, transmitting the converted data 
to the computer via the RlU/data bus. The SCU shall also provide Digital to Analog conversion, 
high level continuous discrete outputs and high level momentary discrete outputs. 


ACS SIGNAL CONDITIONING UNIT FUNCTIONAL BLOCK DIAGRAM 


CMG GIMBAL CMDS 
CMG RESOLVER INPUTS 
RATE GYRO INPUTS 
SUNSENSOR INPUTS 


MOMENTARY DISCRETES 



CMG GIMBAL CMDS 


ACS MOMENTARY 
DISCRETES OUT 


ACS CONTINUOUS 
DISCRETES OUT 



POWER MODULE DMS SIGNAL INTERFACE SUMMARY 


This chart summarizes the measurement and command interface requirements with the DMS RIU's and 
EU's. It includes the analog discrete and digital word measurement input requirements and the 
discrete and serial digital c mmand output requirements. It should be noted that the signal 

interfaces between the ACS and the ACS signal conditioning unit are shown on this chart, and 
that a serial digital interface between the RIU/EU and ACS SCU is assumed. 


POWER MODULE DMS SIGNAL 

INTERFACE SUMMARY 
MEASUREMENT 

INPUTS 

COMMAND OUTPUTS 




Digital 


SERIAL 


ANALOG 

DISCRETE 

words 

DISCRETE 

DIGITAL 

ELECTRICAL 






POWER PROC 

160 

68 

12 



BATTERIES 

36 




24 

NETWORKS 

38 

78 



1 

COMMUNICATIONS 

8 

27 


20 

1 

MECHANICAL 






STRUCTURES 






MECHANISMS 


12 




UMBILICALS 






ATTITUDE CONTROL 


14 

2* 

53 

1* 

CMG 

35 





RATE GYRO 

18 





SUN, SENSORS 

5 





SOLAR ARRAY 






ATRICULATION SYS. 

12 

32 


10 

1 

THERMAL CONTROL SYS.** 

TBD 

TBD 


TBD 

TBD 

DATA MANAGEMENT 

9 

23 


33 

3 

SPARES 

42 

45 




PAYLOAD 

no 

48 


60 

_3 

TOTAL 

473 

347 

14 

176 

34 


♦SERIAL DIGITAL INTERFACE BETWEEN RIU/EU AND ACS SIGNAL CONDITIONING UNIT. 
♦♦INCLUDED IN SPARES 


POWER MODULE INTERFACE COMPONENT USE SUMMARY 


This chart indicates the number of Remote Interface Units (RIU), Expander Units (EU) and 
ACS Signal Conditioning Unit (SCU) required to provide the measurement and command signal 
interfaces with the subsystems. This includes a serial digital interface between the 
ACS Signal Conditioning Unit and the RIU/EU. 

The charts indicate the number and type of measurements and commands going to the units 
and the spare channel capability available for each type of measurement and command. 

As shown, for a simplex system, 5 RIU's and 8 EU's are required. For a dual redundant 
system, each measurement and command would be redundant and 10 RIU's and 16 EU's would be 
required. Two ACS SCU's would be required for a dual redundant configuration. 
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POWER MODULE INTERFACE COMPONENT USE SUMMARY 


INTERFACE 

QTY 

ANALOG 

MEASUREMENTS 

DISCRETE 

MEASUREMENTS 

SERIAL 

DIGITAL 

MEASUREMENTS 

DISCRETE 

COMMANDS 

SERIAL 

DIGITAL 

COMMANDS 

ANALOG 

COMMANDS 

COMPONENT 

REQUIRED 

USED 

SPARE 

USED 

SPARE 

USED 

SPARE 

USED 

SPARE 

USED SPARE 

Used 

RIU 

5 

440 

0 

56 

0 

14 

2 

135 

496 

34 64 

0 

EU 

8 

0 

16 

277 

27 

0 

0 

0 

0 

0 0 

0 

ACS SCU 

1 

42 


14 


0 

„ 

51 


0 

6 


PERCENT OF DATA BUS CAPABILITY UTILIZED 


This chart shows the percent utilization of the allocated Data Bus slots in the STAAC System 
considered as baseline for this study. 
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TYPICAL SOFTWARE DEVELOPMENT FACILITY 

This chart depicts a block diagram of a typical Software Development Facility which would be used to 
develop Power Module flight and pre-flight software. The Software Development Facility provides the # 

capability for flight program checkout in a realistic flight environment. An unmodified flight *' 

program resides in a flight computer and data management system. The facility equipment includes s ., 

a unique designed Flight Computer Interface Device to provide an interface between the flight computer 
and the host computer. The hardware functions are as follows: ? 


o The host computer controls the simulation facility. In addition, it simulates 
the vehicle inputs to the flight computer and monitors the flight computer's 
outputs. 

o The magnetic tape units are primarily used for recording output data from the 
flight computer for post simulated-flight data reduction. 

o The system disk is used for storage of the host computer programs and off- 
line generated display images used during flight program checkout. 

o The bulk storage disk is used for recording flight data for the purpose of 
performing real-time data reduction. 

o The line printer is an output device used for hard copy requirements. One of 
its principal uses is to supply output listing from the language processors 
' used in generating programs for the Facility. 



o The card reader is an input device used by the system to read assembly job and run ques. 

o The display unit provides the user of the system a dynamic view of the system 

according to his requirements. The keyboard, light pen, and function keys in 
the unit permit the user to provide inputs to the system and interface directly 
with the real-time operations. 

o The console keyboard/printer permits the operator to initiate and control computer 
operations. 
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TYPICAL POWER MODULE SOFTWARE DEVELOPMENT FACILITY 
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POWER MODULE SOFTWARE DEVELOPMENT COST SUMMARY 


This chart summarizes the costs for power module software development. The items included in each 
cost are as follows: 

o The flight software includes the design code and verification of 13K lines of 
code with a 115% rework of the code assumed during development. 

o The preflight software includes the design, code, and verification of UK lines 
of code with 115% rework of the code. The verification of preflight software 
is less stringent than that for flight software. 

o The software development facility (SDF) costs include the host computer, flight 
computer to host computer I/O equipment, the power module simulator software 
in the host computer, the I/O equipment test software, the SDF requirements 
definition and SDF maintenance. 

o The SDF flight hardware includes the computer, stint, and central unit. 

o The computer time rental includes the rental of a high capability computer to 
perform off-line functions and calculations. 

o The support software includes the digital interpretive simulator and miscellaneous 
performance analysis software tools. 


POWER MODULE SOFTWARE DEVELOPMENT COST SUMMARY 



FUNCTION 

COST 

0 

FLIGHT SOFTWARE (13K INSTRUCTIONS + DATA) 

1.93M 

0 

PREFLIGHT SOFTWARE (11K INSTRUCTIONS + DATA) 

.52M 

0 

SOFTWARE DEVELOPMENT FACILITY (SDF) 

1.74M 

0 

FLIGHT HARDWARE FOR SDF 

.37M 

0 

COMPUTER TIME RENTAL 

.05M 

0 

SUPPORT SOFTWARE 

.19M 


POWER MODULE SOFTWARE DEVELOPMENT COST DETAILS 


Flight Software - The software design and code process sized for this study includes the system 
design, program definition and program development. Emphasis was placed on analysis of system 
capabilities, development of control laws and redundancy management algorithms, and analysis and 
simulation of these control laws and algorithms in a realistic flight environment. 

Verification test plans and operational procedures were sized to assure that the flight program 
performs in accordance with the established definition, meets mission requirements, and satisfies 
mathematical and logic constraints with no unusual timing interferences. 

Preflight software - The preflight software is similar to that used for Skylab. It is a set of 
ground based modules used primarily to verify the internal options of the flight computer and 
signal conditioning unit including their I/O interfaces. It was sized as an aid in testing 
and evaluating the performance of the Power Module system components during (1) lab simulation, 

(2) post manufacturing testing, (3) vibration and thermal vacuum testing, and (4) readiness testing 
at the launch site. 

Software Development Facility (SDF) - The SDF cost estimates include the engineering and programming 
support activities for interfacing the host computer and the required I/O Hardware. Applications 
and test software were sized to support both the host and I/O hardware under laboratory conditions. 

This software provides the capability for preflight and flight development and checkout in a realistic 
flight system environment. Maintenance of this software was also included in our cost estimates. 

Support software - The cost estimates for the support software include the cost of building the Digital 
Interpretive Simulator and the Assembler/Linkage Editor to support it and the rest of the SDF. Also 
sized were miscellaneous performance analysis software, such as data reduction and analysis programs, 
and a Flight Computer Interpretive Simulator for checking out flight performance parameters. 


POWER MODULE SOFTWARE DEVELOPMENT COST DETAILS 


NSSC-II 

0 FLIGHT SOFTWARE 

DESIGN AND CODE $ .956M 

VERIFICATION .971M 

TOTAL $1.93M 

0 PREFLIGHT SOFTWARE 

DESIGN AND CODE $293K 

VERIFICATION 223K 

TOTAL $51 6K 

o SOFTWARE DEVELOPMENT FACILITY 

HOST COMPUTER AND I/O HARDWARE 620K 

HOST COMPUTER SOFTWARE 752K 

I/O TEST SOFTWARE 196K 

SDF REQUIREMENTS DEFINITION 37K 

SDF MAINTENANCE 130K 


TOTAL 


$1 ,735K 


POWER MODULE SOFTWARE DEVELOPMENT COST DETAILS (CONTINUED) 


t SUPPORT SOFTWARE 

DIGITAL INTERPRETIVE SIMULATOR 169K 

MISCELLANEOUS PERFORMANCE ANALYSIS SOFTWARE 17K 

ASSEMBLER AND LINK-EDITOR LOADER GFE 

FLIGHT COMPUTER INTERPRETIVE SIMULATOR GFE 

TOTAL 186K 
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FEATURES OF FMDM AND DACS HARDWARE 


This chart compares some of the salient features of the DACS and FMDM hardware. Capabilities 
of developed modules are compared as well as identifying some of the development work to be 
done with either system. If either of these two systems are used there will be some development 
work to be done, but this will be a necessary requirement to tailor any off-the-shelf system 
to meet the Power Module requirements. 

The outstanding difference in architecture of these two systems is in the internal data bus 
structure. The FMDM transfers all data from the I/O modules to the processing unit via a serial 
data bus where the DACS uses an 8 bit parallel bus. This difference results in a greatly 
reduced speed capability for the FMDM. 


FEATURES OF FMDM AND DACS HARDWARE 


PARAMETER 

DACS 

FMDM 

INTERNAL DATA BUS 

8 BITS PARALLEL 

SERIAL 

SYSTEM DATA BUS INTERFACE 

MIA 

MIA 

A/D CONVERTER MODULE 

11 BITS PLUS SIGN 

9 BITS PLUS SIGN 

ANALOG MUX CARD 

32 CHANNELS DIFFERENTIAL 
64 CHANNELS SINGLE ENDED 

32 CHANNELS DIFFERENTIAL 
32 CHANNELS SINGLE ENDED 

D/A CONVERTER 



RESOLUTION . 

NO. CHANNELS 
OUTPUT VOLTAGE RANGES 

12 BITS 
8 

6 PROGRAMMABLE RANGES 
0 to +10V, 0 to +5V, 0 to 2.5V 
+ 10V, + 5V, + 2.5V 

10 BITS 
16 

+5.11V to -5.12V 

DISCRETE INPUTS 

72 

48 

DISCRETE OUTPUTS 

72 

48 

SERIAL DIGITAL I/O 

4 SERIAL I/O CHANNELS 

4 SERIAL I/O CHANNELS 

TRANSPONDER I/F 

TO BE DEVELOPED 

TO BE DEVELOPED 

NSSC II I/F 

(IN DEVELOPMENT) 

BOTH DMA AND DIRECT I/O 

DIRECT I/O 


DMS OPTIONAL CONFIGURATION #1 USING DACS HARDWARE 


This chart shows a redundant Power Module DMS configuration using DACS hardware. There 
are some distinct advantages to this DMS configuration as listed below. 

o Backup spare for each DACS unit. 

o Multiple automatic (power switched) configurations. 

o Any DACS unit can be automatically powered off and its spare switched on. 

o One DACS unit dedicated to the ACS/NSSC II interface and also providing an , 

interface to all telemetry data and the command system. 

o One DACS unit dedicated to telemetry formatting and command decoding. This 
unit interfaces with all other DACS units. 

o Self test capability resident within each DACS unit. 

The configuration shown on this chart provides one microprocessor dedicated to the NSSC-II/ 

ACS interface. A data bus link is also provided to the telemetry processor/controller for 
obtaining data from or inserting data in the telemetry data stream. This microprocessor 
will perform the functions of reading ACS signals and storing the data in the NSSC-II memory 
via the DMA Port. Commands to the ACS will be performed sequentially using DMA for the 
output command or Direct I/O for those commands which are required and are not part of the 
normal update sequence. 

A second microprocessor will primarily be used to control the sequence of data collection 
and formatting of the data into the telemetry data stream. This microprocessor will also 
provide the required data to the NSSC-II from the telemetry data stream. 

The MIA modules used for data bus interface contain two isolated I/O parts. The dual Port 
MIA make it possible for one MIA to communicate with either the prime or backup unit depending 
on which unit is powered on. This configuration provides the capability that any DACS unit 
may be powered off and replaced by its backup via power switching to the DACS units. 


















































DMS OPTIONAL CONFIGURATION #2 USING FMDM HARDWARE 


This chart shows a redundant Power Module DMS configuration using FMDM hardware. 

The salient features of this DMS configuration are listed below. 

o Backup spare for each FMDM module. (All modules continuously powered on). 

o Fail safe dual redundant design. 

o One simplex FMDM unit dedicated to NSSC II interface, telemetry formatting 
and command decoding. An identical unit is provided as a backup spare. 

o Three dual redundant FMDM units interface the powered on simplex FMDM unit 
to the Power Module subsystems. 

The DMS configuration shown on this chart uses a Flex MDM to interface the NSSC- I I Computer 
with the other components of the DMS. The Flex MDM contains a microprocessor which can be used 
to perform functions required for data collection, storing of data and transferring data blocks 
to the NSSC- I I via the NSSC- I I ' s direct I/O port. The microprocessor can also be used for 
issuing output commands to the onboard subsystems or other tasks as required by the Active 
NSSC- I I Computer. Modules within the Flex MDM will perform other functions such as telemetry 
formatting, command decoding and interfacing with the orbiter. A MIA module provides a data 
bus interface to other MDMs configured as dual redundant units. The dual redundant MDM will 
use a sequencing memory for Controlling the I/O modules and transferring data to the Flex MDM 
via the data bus. 

The main disadvantage to this system is the time delay from data acquisition to storage in the 
NSSC- I I memory. The MDMs and Flex MDM uses an internal serial data bus to transfer data from 
the I/O modules to the microprocessor or sequencer. The data from an I/O module in an MDM must 
pass over the Internal serial bus, the external serial bus to the Flex MDM, be stored in the 
Flex MDM and then block transferred to the NSSC- II. In some cases the data could be too old 
for reliable computations. A study should be made before assigning measurements to remote 
modules. The delay could be reduced for some measurements by using I/O modules within the Flex 
MDM and eliminate one serial data bus delay. 
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MICROPROCESSOR UTILIZATION REQUIREMENTS 


Assuming that one or more microprocessors are resident within the Power Module DMS, a study 
was made to determine if the microprocessor(s) could be efficiently utilized to reduce the 
workload of the main processor. The following chart lists a set of goals to be used for 
determining the benefits of off loading work from the main processor to the microprocessor. 
The chart also lists guidelines for the selection of software functions to be transferred 
from the main processor to the microprocessor. 


MICROPROCESSOR UTILIZATION REQUIREMENTS 


o GOALS FOR TRANSFERRING WORKLOAD FROM THE MAIN PROCESSOR 
TO THE MICROPROCESSOR, 

o MINIMIZE MAIN PROCESSOR WORKLOAD 

o MUST PROVIDE COST REDUCTION OR 
IMPROVED SYSTEM PERFORMANCE 

o MAXIMIZE EFFICIENT UTILIZATION OF MICROPROCESSOR 


o GUIDELINES FOR SELECTION OF MICROPROCESSOR SOFTWARE FUNCTIONS 

o EXTRACT BLOCKS OF CODE THAT 

REQUIRE FEW INPUTS 
COMPUTE ON FAST CYCLE 
EXECUTE ON A FIXED TIME 
GENERATE FEW OUTPUTS 


MICROPROCESSOR SPEED ANALYSIS 


The feasibility of using a microprocessor v/as investigated by considering two classes of 
tasks: data transfer and math computation. 

A Z80A class microprocessor was assumed for the feasibility study. No attempt was made to 
reconwend a microprocessor. A math chip v/as selected to address math computation. A direct 
memory access (DMA) port was assumed to eliminate instructions in the CPU required for data 
transfer. 

Representative speeds are displayed for information. 

A 3:1 speed ratio of NSSC- I I/micro is a reasonable estimate considering instruction speeds on 
the math chip and extra handling required to move 32 bit words (4 bytes) in a microprocessor. 


MICROPROCESSOR SPEED ANALYSIS 


0 FEATURES ASSUMED 

Z80A CLASS 
4 MHZ 

AM9711 MATH CHIP 
DMA PORT TO CENTRAL CPU 


0 SPEEDS (WITH .AM9711 CHIP) 


FIXED POINT 

MICROPROCESSOR O^SEC) 

NSSC-II (A* SEC) 

LOAD 

3.25 (8 bits) 

2.8 

ADD (32 bit) 

5.5 

2.8 

MULTIPLY (32 bit) 

52.5 

30.4 

FLOATING POINT 

ADD 

52.8 

21.2 

MULTIPLY 

39.3 

33.8 

SIN 

1,202.0 

576.7 

ARCTAN 

1,471.5 

556.5 


0 USE 3:1 SPEED RATIO BETWEEN NSSC-II/MICROPROCESSOR FOR MATH ROUTINES 


MICROPROCESSOR COMPUTATIONAL CAPABILITY 


The computational capability in any microprocessor would require that approximately 35% of its 
processing capability be used for overhead, leaving approximately 65% of its processing 
capability for application processing. 

From the Microprocessor Analysis chart assume a speed ratio of 3:1 for NSSC-II/MICROPROCESSOR, 
then a maximum of 22% of the main processor processing could potentially be performed by a 
microprocessor, assuming that the microprocessor worked at its maximum capability. 

The accompanying chart lists major concerns to be weighed when analyzing benefits of using a 
microprocessor for portions of the Power Module application subroutine functions. It is evident 
that a penalty will result in increased redundancy management complexity and processor 
synchronization that will reduce the actual growth potential gained by using the microprocessor. 
Careful analysis of the actual functions transferred should show the best way to optimize the 
microprocessor usage. Also the use of multiple computers would require multiple Software 
Development Facilities to develop and verify the software functions. 


MICROPROCESSOR COMPUTATIONAL CAPABILITY 


o MICROPROCESSOR OVERHEAD 


- 

PROCESSOR CONTROL 

15% 

- 

DIAGNOSTICS 

10% 

- 

RESERVE 

10% 


TOTAL OVERHEAD 35% 


o COMPUTING CAPABILITY = 100% - 35% (OVERHEAD )= 65% (MICROPROCESSOR CAPABILITY) 

o SPEED RATIO (3:1) INDICATES A MICROPROCESSOR COULD PERFORM PORTIONS OF MAIN PROCESSOR 

COMPUTATION (MAXIMUM OF 22% OF MAIN PROCESSOR KOPS) 

o POTENTIAL CONCERNS WITH USING A MICROPROCESSOR FOR PREPROCESSING 
DATA TRANSFER BETWEEN PROCESSORS SHOULD BE MINIMIZED 
LOGIC BETWEEN CPU/MICROPROCESSOR MUST BE MINIMIZED 
TIMING BETWEEN CPU/MICROPROCESSOR MUST BE SYNCHRONIZED 
MULTIPLE SOFTWARE DEVELOPMENT FACILITIES WOULD BE REQUIRED 
REDUNDANCY MANAGEMENT WOULD BE MORE COMPLEX 


ANALYSIS OF POWER MODULE SOFTWARE FUNCTIONS 


The percentage of total KOPS required for Power Module were estimated for each Skylab/Power 
Module Flight Software major function. The software in each of these areas was examined 
to determine what operations could be moved from the main processor to be performed by a 
preprocessor (microprocessor) and thereby reduce the workload on the main processor for 
greater growth potential . 

It was determined that redundancy management and Program Control could not be moved from 
the main processor. The special functions which are primarily I/O functions are excellent 
candidates to be moved to a microprocessor. The application modules are mainly mathematical 
computations (requiring approximately two thirds of the total KOPS) and contain functions that 
can be handled by a microprocessor. 


ANALYSIS OF POWER MODULE SOFTWARE FUNCTIONS 


FUNCTION % OF KOPS 

PROGRAM CONTROL 14,3% 

SPECIAL FUNCTIONS 11.1% 

APPLICATION MODULES 64.4% 

REDUNDANCY MANAGEMENT 10.2% 


ANALYSIS/PREPROCESSOR OPTION 
BASIC CPU CONTROL (NOT MOVABLE) 
PRIMARILY I/O (EXCELLENT CANDIDATE) 
HEAVY MATH (POSSIBLE CANDIDATE) 

CPU DEPENDENT (NOT MOVABLE) 


CANDIDATE MICROPROCESSOR PROCESSING FUNCTIONS 


Two groups of functions (Special Functions and Application Modules) have been identified as 
potential candidates for microprocessor functions. The Special Functions are primarily I/O 
operations while the application modules are primarily mathematical computations. 

Special Functions - Two approaches are available for a microprocessor to reduce the main processor's 
workload. One approach is for the microprocessor to accumulate I/O data and perform block 
transfers on command from the main processor. The better approach requires a microprocessor 
with a DMA port to the main processor, whereby, the data is stored in the main processor's memory 
in a format requiring minimum manipulation of the data by the main processor. 

This chart assumes that a DMA port is available for determining the possible workload reduction 
to the main processor in KOPS. The three main areas of the Special Functions are listed with 
their relative percentage of the total Power Module program. The net workload reduction to the 
main processor is approximately 8% for the Special Functions area. 

Application Modules - From a previous chart it was shown that the processor could do a maximum 
of 22% of the workload. Assuming that 8% of this processing is utilized for the I/O functions, 
then 14% of the workload (main computer KOPS) could be utilized for the application Modules 
functions. However, additional studies are required to determine what functions can be 
transferred from the main processor to a microprocessor. A "quick look" indicates that most 
application subroutines cannot be easily moved to a microprocessor and that added software 
complexity and technical risk would be involved. 

The structure of the software must be planned from initial concept to final design to use a 
microprocessor or microprocessors in the system. 


CANDIDATE MICROPROCESSOR PROCESSING FUNCTIONS 


o MAXIMUM PROCESSING CAPABILITY - 22% OF MAIN PROCESSOR PROCESSING 

o SPECIAL FUNCTION SUBROUTINE CANDIDATES (ASSUME 90% MOVEABLE) 


- 

TELEMETRY 

2.8% OF KOPS 

- 

INPUT READ 

1 .8% OF KOPS 

- 

OUTPUT WRITER 

4.6% OF KOPS 


TOTAL 

9.2% OF KOPS X 90% = 8.1% OF KOPS 


o APPLICATION MODULE SUBROUTINE CANDIDATES 

A MAXIMUM OF 14% KOPS (22% - 8%) OF THE MAIN PROCESSOR'S 64% KOPS COULD BE 
PROCESSED 

NO SPECIFIC CANDIDATES IDENTIFIED - ADDITIONAL ANALYSIS REQUIRED 

POTENTIAL ADDED SOFTWARE COMPLEXITY AND RISK TO MOVE APPLICATION 
SUBROUTINES TO MICROPROCESSOR 

SUMMARY 

o MAXIMUM OF 22% OF THE FLIGHT PROGRAM COULD BE PERFORMED BY A MICROPROCESSOR 
UP TO 8% OF TOTAL KOPS FOR SPECIAL FUNCTIONS SUBROUTINES 
UP TO 14% OF TOTAL KOPS FOR APPLICATION MODULE SUBROUTINES 
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APPENDIX A 


POWER MODULE SUBSYSTEM 
PROCESSING REQUIREMENTS 


A1 


DMS COMMAND PROCESSING FUNCTIONAL REQUIREMENTS 


FUNCTION 


DESCRIPTION 


• GND COMMAND DECODE 
AND VERIFICATION 


RECEIVE AND DECODE COMMANDS SENT FROM GROUND. • 

VERIFY THAT COMMAND IS VALID (ADDRESS, FORMAT, 

PARITY, SYNC, ETC) 


• ORBITER COMMAND 
DECODE AND 
VERIFICATION 


RECEIVE AND DECODE COMMANDS SENT FROM ORBITER CREW - • 

VIA HARDWARE INTERFACE. VERIFY THAT COMMANDS ARE 
VALID (ADDRESS, FORMAT, PARITY, SYNC, ETC.) 


• COMMAND DISTRIBUTION 
AND CONTROL 


DISTRIBUTE VALID COMMANDS TO USERS IN REAL TIME. • 

ARBITRATE CONTENTIONS BETWEEN GROUND, ORBITER AND 
ON-BOARD STORED/DERIVED COMMANDS. . 


• COMMAND EXECUTION 


EXECUTE COMMANDS SENT TO ELEMENTS ON DMS. • 


• COMMAND STORAGE • PROVIDE STORAGE FOR COMMANDS WHICH ARE TO BE • 

DISTRIBUTED AT LATER TIME (DELAYED). PROVIDE 
CONTROL FOR ISSUING DELAYED COMMANDS AT CORRECT 
TIME. 


I NITIATED BY 

PERFORMED "ON DEMAND". 
MAXIMUM RATE^ 21 CMDS/SEC. 

PERFORMED "ON DEMAND". 
PERFORMED "ON DEMAND". 

PERFORMED "ON DEMAND". 

STORE "ON DEMAND." 

ISSUE DELAYED COMMANDS 
BY TIME TAGS. 


A2 


DMS TELEMETRY PROCESSING FUNCTIONAL REQUIREMENTS 


FUNCTION 


DESCRIPTION 


INITIATED BY 


• TM FORMAT 
GENERATION 


PROVIDE CAPABILITY FOR TBD TELEMETRY FORMATS. 
FORMATS DEFINE DATA CONTAINED IN TM STREAM AS 
WELL AS POSITION OF EACH DATA WORD WITHIN THE 
STREAM. BOTH FIXED AND FLEXIBLE (CAPABLE OF 
BEING CHANGED IN ORBIT FROM GROUND) FORMAT 
REQUIREMENTS REQUIRED AS INPUTS. 


FORMAT SELECTED BY 
GROUND. 

GROUND REPROGRAMS, 
FLEXIBLE FORMAT. 


• TM ACQUISITION • ACQUIRE SYSTEM DATA FOR TM STREAM IN ACCORDANCE 

AND CONTROL WITH APPLICABLE FORMAT. PROVIDE SIGNAL CON- 

DITIONING AS REQUIRED TO PLACE IN DIGITAL WORD 
FORM. INSERT DATA INTO TM STREAM IN CORRECT 
POSITION. CONTROL BIT RATE OF DATA OUT OF DMS. 
PROVIDE CAPABILITY FOR TBD BIT DATA RATES. 


GROUND OR INTERNAL 
SIGNAL (BASED ON FIXED 
TIMELINE AND/OR ORBITAL 
PARAMETERS) TELLS WHEN 
TO SEND TM TO GROUND AND/ 
OR ORBITER. 


GROUND SELECTS BIT DATA 
RATES. 


A3 


DMS ATTITUDE CONTROL FUNCTIONAL REQUIREMENTS 


FUNCTION 


DESCRIPTION 


INITIATED BY 

MODE CONTROL 

0 

CONTROLS OPERATIONAL MODES FOR ATTITUDE CONTROL 
SYSTEM. 

0 

GROUND OR CREW 

REDUNDANCY 

MANAGEMENT 

0 

FAULT DETECTION WITHIN ATTITUDE CONTROL SYSTEM 
COMPONENTS. PROVIDES SWITCHING OF REDUNDANT 
COMPONENTS. 

0 

CONTINUOUS COMPUTATION 

NAVIGATION AND 
TIMING 

0 

POWER MODULE NAVIGATION FUNCTION. MAINTAIN 
ORBITAL TIME FOR EVENT INITIATION. 

0 

CONTINUOUS COMPUTATION 

MOMENTUM 

MANAGEMENT 

0 

PROVIDES MANAGEMENT OF CMG MOMENTUM VECTORS. 
PREVENTS ACCUMULATION OF MOMENTUM. SCHEDULES 
DESATURATION TIMES. 

0 

CONTINUOUS COMPUTATION 

ATTITUDE 

REFERENCE 

0 

PERFORM STRAPDOWN REFERENCE COMPUTATIONS. 

0 

CONTINUOUS COMPUTATIONS 

ATTITUDE CONTROL 

0 

COMPUTE CMG RATE COMMANDS TO CONTROL POWER 
MODULE ATTITUDE. 

0 

CONTINUOUS COMPUTATIONS 


A4 


DMS CREW DISPLAY AND CONTROL FUNCTIONAL REQUIREMENTS 


FUNCTION 

DESCRIPTION 

INITIATED BY 

ORBITER CREW 
DISPLAY 

• PROVIDE DATA FOR DISPLAY ON ORBITER CREW DISPLAY 
CONSOLE AND ON CAUTION AND WARNING PANEL. DATA 
FOR CREW DISPLAY CONSOLE IS A FLEXIBLE DATA SET, 
CONTROLLED BY TBD FORMATS. CREW REQUESTS DATA 
AND FORMAT. C + W DATA IS FIXED DATA SET. 

• CREW DISPLAY CONSOLE 
DATA PROVIDED UPON 
REQUEST OF CREW. THIS 
CAPABILITY AVAILABLE 
ONLY WHEN PM DOCKED TO 
ORBITER. 



C + W DATA ALWAYS 
PRESENT WHEN PM 
DOCKED TO ORBITER. 

CREW CONTROL FOR 
CRITICAL FUNCTIONS 

• PROVIDE FOR CONTROL OF KEY/CRITICAL SYSTEM 

FUNCTIONS THROUGH HARDWARE/DIRECT INTERFACE WITH 
CREW CONTROL PANEL. 

§ PERFORM "ON DEMAND" AT 
CREW REQUEST. 


DMS. ELECTRICAL POWER FUNCTIONAL REQUIREMENTS 


FUNCTION 


• POWER DISTRIBUTION 
CONTROL 


6 SOLAR PANEL CONTROL 


»: 



DESCRIPTION 


INITIATED BY 


CONTROL THE TURN ON/OFF OF POWER BUSES AT 
INTERFACES TO ORBITER AND PAYLOAD, AND AT 
SYSTEM POWER DISTRIBUTORS 


GROUND COMMAND 
OR 

MONITOR CONNECTIONS 
AT UMBILICAL AND 
CONTROL ACCORDINGLY. 


CONTROL DEPLOYMENT, RETRACTION, STOWING AND • GROUND OR CREW 

ARTICULATION OF SOLAR PANELS. COMMAND FOR 

DEPLOYMENT, 

RETRACTION, 

STOWING. 

SOLAR VECTOR MON- 
ITORING AND VEHICLE 
ATTITUDE FOR 
ARTICULATION. 


jS" 
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FUNCTION 

• THERMAL SWITCHING 

• RADIATOR DEPLOY- 
MENT CONTROL 


DMS THERMAL CONTROL FUNCTIONAL REQUIREMENTS 


DESCRIPTION 


• PROVIDE OPERATIONAL CONTROL AND SWITCHING OF COOLING • 
LOOPS AS FUNCTION OF LOAD, POWER MODULE ATTITUDE, 

AND RADIATOR AVAILABILITY 


e 


PROVIDE DEPLOYMENT, RETRACTING, AND STOWING • 

CONTROL FOR RADIATOR PANELS 


INITIATED BY 


CONTINUOUS CONTROL 


THERMAL SWITCHING 
FUNCTION (ABOVE) 
OR 

GROUND OR CREW 
COMMAND. 


A7 


DMS CRITICAL FUNCTION MANAGEMENT FUNCTIONAL REQUIREMENTS 


function 


• CRITICAL FUNCTION 
MONITORING AND 
SWITCHING 


DESCRIPTION 


INITIATED BY 


o MONITOR HEALTH/STATUS OF CRITICAL SYSTEM FUNCTIONS. • CONTINUOUS MONITORING 
SWITCH POWER AND/OR REDUNDANT COMPONENTS ON/OFF UNLESS SWITCHED OUT 

IN RESPONSE TO “OUT OF TOLERANCE" CONDITIONS. BY CREW OR GROUND. 

ALERT GROUND/CREW TO ACTIONS AT NEXT COMMUNICA- 
TIONS TIME. 



DMS SELF TEST FUNCTIONAL REQUIREMENTS 


FUNCTION 

DESCRIPTION 

INITIATED BY 

•v 

• SELF TEST 

• PERFORM SELF TEST AT COMPONENT LEVEL. 

SELF TEST MAY BE PERFORMED UNDER GROUND 
CONTROL OR AUTOMATICALLY AND CONTINUOUSLY. 
COMPILE STATUS DATA FOR GROUND INTERROGA- 
TION VIA TELEMETRY. 

• GROUND OR CREW 
COMMAND. SOME 
COMPONENTS SUCH 
AS COMPUTER MAY 
PERFORM SELF TEST 
ROUTINELY. 


APPENDIX B 


SKY LAB/POWER MODULE 

FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS 


POWER MODULE PRELIMINARY FLIGHT SOFTWARE GENERAL DESCRIPTION 


The following charts present a brief description of each subroutine or function sized in the Power 
Module flight software. The numbering of the descriptions in this section relate to the comparably 
numbered subroutines on the charts on pages 23, 24, and 25 of this presentation. 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 


1.0 PROGRAM CONTROL SOFTWARE 

1.1 EXECUTIVE GENERAL DESCRIPTION AND EXECUTIVE DATA 

The executive control function provides overall control of the onboard flight program and 
its functions, utilizing a set of program modules known as the Executive Control System. 
The Executive Control System consists of the executive program and a common communications 
area which allows for inter-module communications, common data, and mission dependent 
parameters. The executive program, composed of sub-programs and tables, controls the 
execution of applicable modules, services interrupts and routes control to the appropriate 
application module on a priority basis, and provides utility operations. 

The executive program performs interrupt processing, multi-task processing on a priority 
level basis, processes time controlled events via task queuing, processes the power-on 
interrupt, and controls program initialization. 

1.2 INTERMEDIATE LOOP 

The intermediate loop consists of those functional requirements which must be executed 
approximately 5 times per second. Included in this cycle are the following functions: 

1. Intermediate loop processor 

2. Strapdown reference (primary) 

3. Strapdown reference (backup) 

4. CMG control 

5. Input read 

6. Output writer 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 


1.3 SLOW LOOP 


The slow loop execution cycle consists of those functional requirements which must be executed 
approximately once per second. These functional requirements and their execution sequence are: 


1 . 

2 . 

3. 

4. 

5. 

6 . 

7. 

8 . 
9. 


Slow loop processor 
Discrete input processor 
Mission timer processor 
Navigation 

Mode logic processor 
Orbital plane error 
Redundancy management control 
Strapdown (normalization) 

Self test 


The special processing associated with the docked/undocked configurations will also be performed 
on the slow loop priority level. 

2.0 GENERAL PURPOSE UTILITIES 


Utility functions are those functions which are utilized as subroutines by application modules. 
Specifically, utility functions are not application dependent but perform general functions for a 
variety of application modules. The following routines satisfy the utility function requirements: 

Square Root 
Sine/Cosine 
Arctangent 

Matrix by Matrix Multiply 
Vector Dot Product 
Vector Cross Product 
Double Precision Multiply 
Scaled Divide 
Quaternion Multiply 
Alert Update 
Limiting Subroutine 
Set-Reset Routine 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 


3.0 SPECIAL PURPOSE FUNCTIONS 

3.1 POWER UP PROCESSING AND PROGRAM INITIALIZATION 

The power up and initialization routine of the executive control program will be performed 
whenever one of the PM computers is given control, at initial power up or computer switch- 
over. The initialization routine will perform both executive and application system 
initialization, schedule and initial interval timer interrupt, will initiate the flight 
program, and the executive program will maintain program control thereafter. 

3.2 DISCRETE INPUT PROCESSOR 

The discrete input processor samples and discrete input registers once per second and 
specific responses are performed when the presence of a particular discrete is determined. 

3.3 TELEMETRY PROCESSOR 

The telemetry processor will be executed as required and will transmit the TBD specified 
data during the TDRSS access period or via the Orbiter's telemetry system during docking 
periods. 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 

3.4 BCD DISPLAY 

This routine will be executed once per second when the power module is docked with the 
orbiter to provide the astronaut with such data as discrete information to indicate the 
status of various power module subsystems, attitude control data, timing information, 
and command system information. 

3.5 INPUT READ 

This routine will be executed five times per second to read attitude control data via 
the data bus. The data will be stored and made available to the telemetry processor and 
the attitude control processor. 

3.6 OUTPUT WRITER 

This routine's function is to issue the attitude control signals calculated during each 
intermediate loop. Assuming that the same hardware limitations exist on Power Module as 
they were on Skylab, the execution rate for this routine will be 35 times per second 
to effectively utilize the input/output converters. 

3.7 RADIATOR DEPLOYMENT CONTROL 

This routine will be executed once per second to monitor such indicators as docking mode 
free flyer mode, and solar panel deployment. When a new radiator position is required 
this routine determines the number of commands (discretes) required to deploy the 
radiator to the new position. 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 


3.8 DCS MEMORY LOAD BUFFER 

Memory locations reserved for DCS data. 

3.9 COMMON DATA AND DATA 

Two data storage areas are accessible to the flight program. These areas are the common 
memory and those data blocks defined for application module use. Common memory is 
accessible without the use of a base register and consists of two subdivisions - low 
common and high common. Low common is accessible from any part of memory by specifying 
base 0 in the instruction operand. High common is accessible with store base register, 
load base register, and branch and store instructions. Other instructions must use base 
registers to address this storage area. 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 


4.0 APPLICATION MODULES 

4.1 CMG CONTROL 

The CMG attitude control program function consists of sampling CMG momentum from CMG 
direction cosines, Power Module rates from the rate gyros, and attitude errors from the 
acquisition subsystem or strapdown reference and using these inputs to generate CMG gimbal 
rate commands. In addition to attitude control gimbal rate commands, the program generates 
CMG gimbal rate commands for optional CMG orientation through a steering and rotation 
law. The calculating performed by this program, when applied to the ACS hardware, insures 
that the Power Module has the proper orientation to satisfy mission objectives. 

4.2 CMG GIMBAL ANGLE CALCULATIONS 

The function of the CMG gimbal angle calculation routine is to compute the inner and 
outer gimbal angles from the direction cosines. 

4.3 GRAVITY GRADIENT DUMP 


This program uses the CMG momentum orientation sampled during solar inertial pointing to 
determine the nighttime maneuver profiles required for gravity momentum desaturation. 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 


i 
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4.4 NAVIGATION AND TIMING PROCESSORS 

The navigation function is composed of maintaining an elapsed time reference for other 
functions, maintaining spacecraft positions and velocities, and maintaining relative 
position and attitude with respect to TBD reference. 

4.5 ORBITAL PLANE ERROR 

Orbital plane error computes an orbital plane error angle which provides an attitude 
reference about the Power Module TBD axis for display and telemetry. The angle is also 
utilized in computing the single axis rotation about the TBD to the solar inertial frame. 

4.6 STRAPDOWN REFERENCE 

The function of the strapdown platform is to maintain knowledge of the vehicle attitude with 
respect to an inertial reference. This function is accomplished by performing analytical 
platform calculations using sensed inertial angular rates (or position pulses) from 
reference gyros. 

4.7 COMMAND SYSTEM PROCESSOR 

The command system is made up of an RF digital command system(DCS) . The digital command 
system provides a communication link between the TBD ground stations and flight program. 

The command system provides a limited real time means of controlling specific flight program 
timing, navigation, subsystem management, sequencing functions and obtaining specific 
information for display and telemetry. 
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POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 

4.7 COMMAND SYSTEM PROCESSOR (CONTINUED) 

The program performs a series of tests on each command received to insure the validity of the 
information. Appropriate data is telemetered to the ground and displayed to the crew (while 
docked) to indicate the status of these tests and to indicate the data actually received 
by the flight computer. 

4.8 MODE LOGIC PROCESSOR 

The ACS is required to operate in any one of TBD mututally exclusive primary modes. These 
modes, when suplemented by the mode options available, provide the capability to configure 
The ACS components and flight program to satisfy the mission requirements. 

Request for changes in primary modes or mode options originate from the command system or the 
flight program. Typically, the flight program will request changes in the primary mode 
only as a precautionary measure resulting from detection of a failure. 

ATTITUDE HOLD: Performs maneuvers upon request. 

SOLAR INERTIAL UPDATES: Solar inertial offset biases upon request, maintains the sun 

sensor control indicator, and enables/inhibits Gravity Gradient dump maneuvers. 

RANDOM REACQUISITION: Processes random reacquisition enable/inhibit requests, and performs 

random reacquisition calculations. 

GRAVITY GRADIENT DUMP: Processes and initiates dump maneuvers and processes momentum 

samples and desaturation calculations. 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 

5.0 REDUNDANCY MANAGEMENT 

The redundancy management (RM) tests shall be designed to ensure vehicle survival with any single 
component failure, and with as many non-simultaneous component failures as possible within soft- 
ware word allocations. Vehicle survival requires that solar power input be maintained, thermal 
control of sensitive components be maintained, and ground/vehicle communication links be main- 
tained for a period of TBD days following a component failure. The key element in RM is the 
response time required following a failure for reconfiguration and re-establishment of solar 
reference. Loss of sun incidence on the solar panels to the extent that the electrical power 
system (EPS) is inoperative is the condition that redundancy management must prevent. During the 
survival period, onboard failure isolation under software control, and ground failure isolation 
operations (effected using the DCS command link), will be exercised to eliminate the failed 
component from the vehicle operation. Following failures for which no redundant component or 
operational mode exists aboard the PM, the survival mode must permit safe rendezvous and 
docking of the space shuttle for return to earth. 

CMG RM TBD 
RATE GYRO RM TBD 
RM CONTROL SW TBD 
SUN SENSOR TBD 
SELF TEST TBD 
SWITCHOVER TBD 
HEALTH CHECK TBD 


POWER MODULE FLIGHT SOFTWARE SUBROUTINE DESCRIPTIONS (CONTINUED) 


6.0 POTENTIAL GROWTH FUNCTION 

6.1 SOLAR ARRAY POINTING TBD 

6.2 THERMAL CONTROL TBD 

6.3 POWER DISTR CONTROL TBD 


